IAM Users, Groups, and Roles

The cornerstone of AWS security is provided by a global service called AWS IAM, which stands for Identity and Access Management (IAM). AWS Identity and Access Management (IAM) is a service that enables you to manage access to AWS services and resources securely by controlling user authentication and permissions. Only after identity has been established is authentication granted, and permissions authorized.

Understanding Identity and Access Management (IAM) is critical for the SAA-C03 exam, as the Design Secure Architectures domain accounts for 30% of the exam. In designing solutions, the concepts of IAM users and groups, as well as when to use roles, are essential.

At the end of this post are three multiple-choice test questions to test your knowledge.

Identity and Access Management

AWS Identity and Access Management (IAM) is the backbone of securing your AWS cloud environment. It allows you to control who (or what) can access your AWS resources, ensuring only authorized users, applications, or AWS services perform specific actions.

Figure 1: The IAM Dashboard

Let’s break down the concept of IAM Users, IAM Groups, and Roles, focusing on configuration and some best practices.

IAM Users

An IAM user should represent an administrative-type person, such as an engineer, who interacts with AWS services and resources on a daily basis. IAM users can be assigned various credentials, including passwords and access keys. Creating individual IAM users allows you to limit their permissions to just the tasks and resources that are needed for the job.

Best Practice: Always enable Multi-Factor Authentication (MFA) on each IAM account created to enhance security, like two-factor authentication in enterprise networks.

A newly created IAM user has no permissions assigned by default, adhering fully to the principle of least privilege. Permissions are assigned to an IAM user by attaching security policies to each IAM user. For example, you could attach the "AmazonS3ReadOnlyAccess" managed policy to allow an IAM user to read S3 buckets.

Figure 2: A single IAM policy

A managed policy is part of a library of default security policies created and maintained by AWS IAM. Each IAM policy, once linked to an IAM user, IAM Group, or role, allows a specific task or tasks to be performed by the IAM user, group, or role. IAM defines a principal as either an IAM user, IAM group, or role.

Figure 3: There are hundreds of already created IAM policies that can be deployed.

Suppose you’re managing several EC2 instances hosted in a specific VPC: For this example, your IAM user account can be given the exact permissions to launch or terminate EC2 instances.

The attached IAM policy would include permissions for EC2 instance management (e.g., launching, stopping, and terminating), VPC configuration (e.g., security groups, subnets, and route tables), and other related services such as Elastic Block Store (EBS) for storage.

Note that the listing below only shows a partial list of the required permissions.

Figure 4: Policy actions for complete management of an EC2 instance (partial JSON listing)

Optionally, one can attach the managed policy "AmazonEC2FullAcces ” to grant full EC2 access. Granting full access is easy, but it is also not recommended for everyone. After all, not every administrator needs full access.

IAM Groups

An IAM group is a collection of IAM users which can help simplify the management of assigning permissions. For example, you might create a "VPCAdmins" group for users managing network configurations, attach the required IAM policies to the group, and then add network administrators to the group. Instead of assigning policies to individual IAM users, you can assign them to an IAM group, and all users in the group will inherit the assigned permissions.

A user can also belong to multiple groups. For instance, "NetworkAdmin" could be in both "VPCAdmins" and "Developers" groups, inheriting permissions from both groups.

IAM Groups cannot contain other groups, and there are no default groups. This is similar to managing user groups in Active Directory for network access control.

Best Practice: Use IAM groups to manage permissions for users with similar duties, reducing administrative overhead, much like grouping users in a network management system.

Figure 5: NetworkAdmin is a member of both IAM groups.

IAM Roles

An IAM role is an identity with specific permissions that IAM users or AWS services can request to assume to carry out the requested action. Roles are ideal for scenarios where you don’t want to use long-term credentials, such as granting an EC2 instance access to an S3 bucket as required.

Requests to assume the use of an IAM role for access are made to a service called the Security Token Service (STS).

Each role is created with an attached trust policy defining who can assume the role (e.g., an EC2 instance or an IAM user from another AWS account). The role/trust policy handoff to STS effectively communicates, “Here’s what I want to do, here’s the trust policy indicating that I am allowed to assume this role.”

Figure 6: The trust relationship defines the Action request to STS to assume the actions the attached role allows.

Therefore, a role can be created to allow an EC2 instance to access an S3 bucket when required without additional user credentials.

Figure 6: The EC2 instance is assigned a role allowing S3 access.

IAM Users vs IAM Roles

IAM users with attached policies are allowed to access AWS services after IAM has verified their attached “allow” permissions. Note that an IAM user must first be authenticated and identified before they can request anything. When using a role to carry out a task, the request for access using an IAM role must be verified by the Security Token Service. If the presented IAM role and trust policy are verified, STS provides temporary credentials for a one-hour session. After one hour is up, reauthentication with STS is required. The use of temporary credentials and trust policies makes IAM roles a better choice for controlling access to AWS resources by AWS services. Cross-account access in AWS Identity and Access Management (IAM) allows users, roles, or services in one AWS account to access resources in another AWS account.

Figure 7: Cross Account Access with IAM Role Assumption Process.

IAM Policies

IAM policies are JSON documents that define explicit allow permissions, which are the actions that can be taken (Create, List, Delete, Describe) on resources (EC2 instances, S3 buckets). Policies are of two types:

Identity-Based Policies: Attached to users, groups, or roles.

Resource-Based Policies: Attached to resources like S3 buckets.

Best Practice: Follow the principle of least privilege, granting only necessary permissions, similar to configuring firewall rules to allow specific traffic.

Exam Tips for IAM Users, Groups, and Roles

To excel in the SAA-C03 exam, focus on these key IAM concepts:

Principle of Least Privilege: Grant only the permissions needed. For example, use "AmazonS3ReadOnlyAccess" instead of "AmazonS3FullAccess" for read-only tasks.

Roles Over Users: Utilize roles for AWS services (e.g., EC2 accessing S3) and cross-account access to prevent the use of long-term credentials, thereby enhancing security.

Group-Based Management: Assign permissions to groups, not individual users, to streamline administration, especially for large teams.

Policy Evaluation: Understand how AWS evaluates policies. Explicit allows grant access. An explicit denial in any policy (identity-based or resource-based) takes precedence.

MFA: Enable MFA for all users, especially those with elevated permissions, to align with security best practices.

Pro Tip: For scenario-based questions, identify whether the solution requires a user, group, or role based on the context. (e.g., temporary access = role, user management = group)

Sample Exam Questions

Here are three sample questions to test your understanding of IAM Users, Groups, and Roles, each with two correct answers, two incorrect answers, and explanations referencing AWS documentation.

Question 1

Which of the following statements are true about IAM users? (Choose two.)

A. IAM users can have both console access and programmatic access.

B. IAM users are created with full administrative permissions by default.

C. IAM users can be part of multiple groups.

D. IAM users can assume roles themselves to gain additional permissions.

Correct Answers: A, C

Explanation:

A is correct because IAM users can have console access (via passwords) and programmatic access (via access keys).

C is correct because users can belong to multiple groups, inheriting permissions from the groups they belong to.

B is incorrect because new IAM users have no permissions by default, requiring explicit policy attachments after initial creation.

D is incorrect because users can only assume roles after a role and trust policy have been created and assigned.

Question 2

What is the purpose of IAM groups? (Choose two.)

A. To organize IAM users and assign permissions to them collectively.

B. To provide temporary credentials for AWS services.

C. To manage cross-account access.

D. To simplify permission management for multiple users.

Correct Answers: A, D

Explanation:

A is correct because groups organize users and assign permissions collectively.

D is correct because groups simplify permission management by applying policies to multiple users, as noted in the same documentation.

B is incorrect because roles, not groups, provide temporary credentials.

C is incorrect because cross-account access is typically managed with roles, as outlined in Cross-Account Access.

Question 3

When should you use an IAM role instead of an IAM user? (Choose two.)

A. When you need to grant permissions to an AWS service, like Amazon EC2.

B. When you need to provide access to a third-party application.

C. When you need to manage permissions for a group of users.

D. When you need to provide temporary access to a user from another account.

Correct Answers: A, D

Explanation:

A is correct because roles grant permissions to AWS services (e.g., EC2 accessing S3).

D is correct because roles can provide temporary access for users from other AWS accounts.

B is incorrect because third-party applications typically use IAM users with access keys.

C is incorrect because groups, not roles, manage permissions for multiple users.