Understanding AWS IAM (Part 1)

If you have ever used AWS (i.e. Amazon Web Services for the uninitiated), I am sure you would have came across the concept of IAM. Now most people when starting with AWS try to directly jump on to core computing and managed services like ec2, lambda, s3, rds etc.

However, what I’ve found through out my experience of working with AWS for past 4 years is that, no matter what AWS service you are using you would need to learn and understand about AWS IAM to efficiently and securely manage those services.

Alright, so what is AWS IAM?

IAM stands for Identity & Access Management. It’s a global service and is completely free that AWS provides to all its users to properly manage the access to their AWS resources. In other words, it helps the AWS users in controlling the access to their AWS resources by managing user authentication and authorisation. If you are not aware of what is the difference between authentication and authorisation, please read my following post before continuing.

Now let’s understand how AWS IAM manages authentication and authorisation. In IAM authentication is managed using Identities and Authorisation is managed using Access. In this part of this IAM series, we are going to talk about Identities. Let's get started.

IAM Identities

Identities is basically what it is, it’s the identity of the user or application trying to access any AWS resource. Using Identity AWS IAM verifies whether the user is even allowed to enter and log in to the system or not. Now there are multiple types of identities that are present in AWS IAM and they are root user, individual user, groups and roles.

Among all the above mentioned IAM identities, Roles are somewhat of a tricky topic, so let’s dive a little bit deeper into it and try to understand what exactly is a role. All the other identities mentioned above except roles, are assigned to the user or application, have some sort of credentials associated with them (like password or keys) and is retained by them over a long period of time. However, roles function a little differently. First of all, roles are not assigned to the user, they are assumed by the user temporarily for the duration of the task. Secondly, because they are assumed by the user, they don’t have any credentials. This is the key difference between roles and other identities.

Now let’s take a look at a security design principle which is at the core of not just AWS IAM but various other cloud service providers access management systems.

Principle of Least Privilege

What principle of least privilege states is that NO user should be granted more access than they need or in other words, all users must get minimum access to get the job done.

Now this obviously makes sense, as the more unnecessary access you give to a user, the more you increase the chances of an unauthorised security breach to your critical cloud resources.

That's it for this part folks.

In the next part of this series, We will be diving into how access is used in AWS IAM to manage authorisation and what are different ways of defining access in AWS IAM. The next part is now published and you can read it here.