IAM Users and Groups

IAM Users and Groups

In this tutorial we are going to explore about the AWS IAM Users and Groups. IAM Users and Groups are core components of AWS Identity and Access Management (IAM) that enable you to manage access to AWS resources for individual users and collections of users within your organization.

Let’s now learn more about the IAM identities, starting with IAM users and IAM groups.

IAM Users

An IAM user is an identity that represents a single individual, application, or service that needs access to AWS resources. It is used when we want to provide long-term credentials to an entity. Using the IAM user credentials, the principal entity can authenticate itself with AWS and log in to the account. However, by default, the IAM users cannot perform any function besides logging into the account. To authorize the user to perform the required actions, we attach the IAM policy with the IAM user. The policy defines the scope of permissions of the user. So, the IAM user identity handles user authentication, while the attached policy is responsible for authorization.

IAM users can have login credentials for the AWS Management Console (username and password) and programmatic access credentials (access key ID and secret access key).

When to use IAM users

Here are a couple of scenarios where we can use IAM users:

Secure the root account

The main account that we create on AWS is a root account. It has all the privileges and can perform all sorts of operations. Using this account for day-to-day operations is not recommended, as it can be used to change the account settings. So, to start off, we should create an IAM user with administrative access and use that account instead of the root account. Here are some of the sensitive operations that can only be performed using the root account:

• Change our account configurations
• Modify our billing settings
• Close our AWS account

These are very rarely used and very sensitive operations, so by using an IAM account instead of the root account, we restrict the use of these operations.

Provide access to principal entities

An organization usually consists of different operational units. For example, there can be admins, developers, QA, and many other departments. We can provide each of them with an IAM account with permission to perform only their respective tasks. By doing so, not only are we providing them with the required access but also making sure that they do not have permission to do anything out of their scope of work.

IAM user workflow

When creating an IAM user, it will provide a username and a password for the user. The specific entity can then use these credentials to log in to the AWS account. Along with these basic credentials, we can use some other credentials for authentication. The choice of authentication credentials depends upon the type of access required. Aside from the username and password that we use to log in to the AWS console, the other credentials are as follows:

• Access keys: These credentials are useful when we make programmatic calls to AWS. They consist of AWS ACCESS ID and AWS SECRET KEY.
• SSH keys for use with CodeCommit: This is a public SSH key that can be used to authenticate with CodeCommit.
• Server certificates: These are SSL/TLS certificates that we can use to authenticate with some AWS services.

When a request is made with any of these credentials, the request is examined by IAM. It first authenticates the principal entity and then evaluates the request contents against the policy associated with the IAM user. If the user is permitted to execute the action, IAM grants authorization to proceed with the request. Otherwise, the request is rejected, and an appropriate error statement is returned as the response.

IAM groups

An IAM group is a collection of IAM users. These groups are used when multiple users require the same type of authorization. In such a case, instead of attaching a policy with each of these users, we attach the required policy with a group and add the users to that group. By doing so, we provide the users with the required permissions in one go. This makes managing the policy much easier.

Consider an organization with multiple departments having more than one user in each department. Attaching policies with the IAM users for these roles will not only be time-consuming but also might lead to inconsistencies in policies for the same kind of roles. To cope up with this issue, we can create an IAM group for each of these departments, and then instead of adding policies with the users, we can add the users in their respective groups.

Please note that IAM groups cannot be used for authentication. We can add a user in multiple groups. In such a scenario, the user will have permissions allowed to all the associated groups. Groups, however, cannot be cascaded. You attach policies to groups, granting permissions to all users within that group. Users inherit permissions from the groups they are a member of, and you can add users to multiple groups as needed.

Example Groups

• Admins: A group for administrators with permissions to manage all resources.
• Developers: A group for developers who need access to services like EC2, S3, and Lambda for development tasks.
• ReadOnlyUsers: A group that grants read-only access across AWS resources, suitable for auditors or stakeholders who only need to view configurations.

Advantages of Using IAM Groups

• Simplified Permissions Management: By grouping users and attaching permissions to groups, you streamline permission changes and maintain consistency.
• Role-Based Access Control: Groups make it easy to implement access control based on organizational roles.
• Scalability: Adding new users to groups instantly grants them appropriate permissions, saving time on individual policy management.

How IAM Users and Groups Work Together

Lets discuss about how IAM Users and Groups Work Together

• User Creation: When you create an IAM user, it has no permissions by default.
• Adding Users to Groups: You can assign the user to one or more groups, granting them the group’s permissions.
• Direct Policy Attachments (Optional): If a user requires unique permissions not covered by their groups, you can attach policies directly to the user. However, using groups is recommended for easier management.

Example Scenario

Let’s say your organization has an IT team with administrators, developers, and analysts:

1. Admins Group:
   • Permissions: Full access to manage all AWS resources.
   • Users: Admin team members are added to this group.
2. Developers Group:
   • Permissions: Access to EC2, S3, and DynamoDB, but restricted from modifying IAM.
   • Users: All developers are added to this group.
3. ReadOnly Group:
   • Permissions: View-only access across AWS services.
   • Users: Analysts and business users who only need to view resources and configurations.

Best Practices for IAM Users and Groups

Following are the Best Practices for IAM Users and Groups

1. Use Groups for Permissions Management: Groups provide a scalable way to manage permissions, so use them whenever possible rather than assigning policies to individual users.
2. Apply the Principle of Least Privilege: Only grant permissions necessary for each role. Avoid giving broad permissions to groups or users.
3. Enable Multi-Factor Authentication (MFA): For users with console access, especially those in sensitive groups, enable MFA for added security.
4. Rotate Access Keys Regularly: For users with programmatic access, rotate their access keys to maintain security.

In summary, IAM users and groups are foundational tools for managing permissions in AWS. IAM users represent individual entities requiring access, while IAM groups simplify permissions management by grouping users with shared permissions, providing an organized, scalable way to control access to AWS resources.

That’s all about the Core components of AWS, i.e., IAM users and groups. If you have any queries or feedback, please write us at contact@waytoeasylearn.com. Enjoy learning, Enjoy AWS Tutorials.!!