In this blog we will understand the important elements of IAM namely the User, IAM Group, and IAM Role:
a. User: An IAM user is a person who utilizes an AWS service in an AWS account. As we discussed in the previous blogs, we know that AWS has two types of users: i. Root User and ii. IAM user.
(i). Root User: A root user name itself gives a clue that this is the special user. It is created when the AWS account is created for the first time. When you create an AWS account, AWS will create one identity (user) for you. That identity (user) is called the AWS Root user. This user has access to all AWS resources and services in the account.
Let me list a few important points about AWS root user.
- You can sign in as the root user using the email address and password that you used to create the account.
- The root user has complete access to all AWS services and resources in the account.
- Avoid using the root user for everyday tasks.
- Never share root user credentials with anyone.
(ii.) IAM User: Now that we understand, we cannot use the root user for our day-to-day AWS tasks – that’s where the IAM user finds its place in IAM. IAM user is an entity that you (root user) create in an AWS account to represent the user who interacts with AWS resources in your account.
We will understand this with an example. Let’s say you are the team lead in an organization with an AWS account. Your team consists of two developers (Ram and Shyam) and two administrators (Sita and Gita). This team needs access to an AWS account to host an application.
You are an AWS expert and you are well aware of the best practices to follow while working with an AWS account. So, you create an IAM user for each of your team members instead of giving access to your root account. By creating an IAM user for each member you allow access to specific services required by the respective member to perform the assigned task. Each team member represents one IAM user as each team member needs to interact with an AWS account to do their task. So, you will create four IAM users for Ram, Shyam, Sita, and Gita.
Okay, now we understand the IAM user. Let’s look at how an IAM user works and the procedure to assign permissions to different IAM users. When you create an IAM user, the user gets a username, password, access key ID, and secret access key. You will share these IAM credentials with the respective person to access the AWS IAM account. Username and password will be used to access AWS Management Console while access key ID and secret access key are used for programmatic access to AWS Command Line Interface (CLI).
You can notice that each user has been added under a single AWS account. Each IAM user has its own login credentials to access the AWS account. Now let’s discuss what kind of AWS resources the IAM users can use.
- Any new IAM user does not have any default permission to access your AWS resources.
- To allow your IAM users the necessary permission, you need to give them the required permissions. You will do this by adding IAM policies to each IAM user. IAM policy defines the set of permissions that are given to any user interacting with an AWS account. We are going to cover IAM Policy in the next topic.
In a nutshell, you create IAM users, attach IAM policies to give permissions and the user can use these credentials to access these resources. An important point here to note is that an IAM user doesn’t have to represent an actual person. It could be an application also. Let’s say, you have an application hosted on your premises that needs to access an AWS service. So, here you will configure the access key ID in the application to allow access to AWS services. That is another important use case of the access key ID.
b. IAM Group: An IAM group is a collection of users and permissions assigned to these users. Let’s go back to the same example. In your team, you have two developers (Ram, Shyam) and two administrators (Sita, Gita). Developers will have similar job responsibilities and access the same AWS services while the same goes for both administrators as well.
So here, instead of assigning permissions to individual users, you can group the users with common job responsibilities into one group and assign permissions to that group at once. And in our case, you can create two Groups. One group is for developers and the second group is for administrators. IAM Groups provide an easy way to manage permissions for users according to their job functions. So when you create a user, you assign a policy to the individual user. But in the case of a group, you will add a policy to the group and permission will be applicable to all users in that group. Let’s understand this better with one more use case for IAM Group.
Till now, we understand that any user in a specific user group automatically gets the permissions assigned to that user group. If a new user joins your organization and needs administrator privileges, you can assign the appropriate permissions by just adding the new user to that administrator user group. Similarly, if an existing employee is moving to a new project in a new role in the same organization, instead of editing individual users’ permissions, you can remove that employee from the existing user groups and add him/her to the appropriate new user groups.
So, the IAM group is a way to attach policies to multiple users at one time. When you attach an identity-based policy to a user group, all of the users in the user group receive permissions from the user group.
c. IAM Role: An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user attached to IAM Policy that determines what a Role can and cannot do in AWS. Now, you must be thinking, what is the difference between the IAM role and user, right? Let’s understand this. An IAM user is a unique person who has a username, password, and access key ID, with the permissions attached to it. However, the IAM role doesn’t have either a username, password, or access key ID. So the IAM role can’t be directly linked to a person or a service, instead, it can be assumed by a person or resource for a definite session. What does it mean? Let me explain with this image example:
Let’s say you have an application running on an EC2 instance, this EC2 instance wants access to an image stored in S3. In this case, EC2 assumes the role, and based on policy, it will access images from S3. As I mentioned, roles don’t have any access key ID or credentials associated with them. The credentials are temporary and dynamically assigned by AWS. AWS gives the temporary credential to the role to complete the task when it is needed. Once the task is complete, the role is detached from the entity.
In my next blog, we will learn to create IAM User, Role, and Group. Stay tuned!