2.1.1.1. IAM: Users, Groups, Roles, and Policies

2.1.1.1. IAM: Users, Groups, Roles, and Policies

💡 First Principle: AWS IAM provides granular control over who accesses which AWS resources and what actions they perform, ensuring secure, compliant operations via least privilege.

AWS Identity and Access Management (IAM) allows you to manage access to AWS services and resources securely. It's the core service for defining, granting, and managing permissions for your AWS environment.

Key IAM Components:

• "Users": Individual entities (people or applications) with long-term credentials (password, access keys) for direct AWS interaction.
• "Groups": Collections of IAM users. Attaching policies to a group grants the same permissions to all users within it, simplifying permission management.
• "Roles": Secure IAM identities that grant temporary permissions to AWS services (e.g., an EC2 instance accessing S3) or trusted external entities without needing permanent credentials.
• "Policies": JSON documents that define specific permissions (allowed or denied actions on resources). They are attached to users, groups, or roles to enforce access control.
• Policy variables: One policy can serve many users through placeholders resolved at request time — e.g. a Resource of arn:aws:s3:::example-bucket/home/${aws:username}/* gives each IAM user only the folder named after them. ${aws:username} is the friendly user name; ${aws:userid} is the opaque unique ID (e.g. AIDA...), so it does not match a folder named after the person.
• Root user: The account's original identity has unrestricted access that IAM policies cannot limit, and a few tasks only it can perform — e.g. in a standalone account (not in AWS Organizations), closing the account and changing the root user's email address or password; in any account, configuring S3 MFA Delete. Even an IAM user with AdministratorAccess cannot do these, so protect the root user (MFA, no access keys) and sign in as it only for those tasks.

Scenario: Instead of hardcoding S3 bucket credentials directly into an application running on an EC2 instance, an IAM role is assigned to the instance, granting it temporary, secure access to S3.

Visual: IAM Users, Groups, Roles, and Policies

⚠️ Common Pitfall: Attaching policies directly to individual IAM users rather than using groups or roles. This makes permissions difficult to manage and audit at scale.

Key Trade-Offs:

• Users/Access Keys vs. Roles: Users with long-term access keys are simpler for initial setup but carry higher risk if compromised. Roles provide temporary, short-lived credentials, which are more secure for applications and cross-account access but require a bit more setup.

Reflection Question: How does IAM's centralized control and the use of IAM roles enhance security and operational efficiency compared to managing individual, long-term credentials for applications?