🔐

IAM - Identity and Access Management

Users, groups, roles, policies and permissions

⏱️ Estimated reading time: 15 minutes

Introduction to IAM

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. With IAM, you can centrally manage permissions that control which AWS resources users can access.

🎯 Key Points

✓ IAM is global, doesn't require region selection
✓ Free to use, no additional costs
✓ Follow the principle of least privilege
✓ Use MFA for users with elevated privileges
✓ Never share root user credentials

IAM Users

An IAM user is an entity you create in AWS to represent a person or application that interacts with AWS. A user consists of a name and credentials.

Credentials:
- Console: Username and password for web access
- Programmatic: Access Key ID and Secret Access Key for CLI/SDK
- Best Practices:
- Never use root user for daily tasks
- Enable MFA for users with elevated permissions
- Rotate credentials regularly
- Don't embed Access Keys in code

🎯 Key Points

✓ Each user has unique credentials
✓ Maximum 5,000 users per AWS account
✓ A user can belong to up to 10 groups
✓ Policies can be attached directly to users (not recommended)

💻 AWS CLI commands for user management

# Create a new user
aws iam create-user --user-name developer-john

# Create access keys for programmatic access
aws iam create-access-key --user-name developer-john

# List all users
aws iam list-users

IAM Groups

Groups are collections of users that share the same permissions. Groups simplify permission management by allowing you to specify permissions for multiple users at once.

Features:
- Groups can only contain users, not other groups
- A user can belong to multiple groups
- Users don't need to belong to any group
- A group can have multiple policies attached

🎯 Key Points

✓ Groups cannot be nested
✓ Use groups to manage permissions at scale
✓ Organize groups by job function (Developers, Admins, QA)
✓ Apply policies to groups, not individual users

💻 Group management with AWS CLI

# Create a group
aws iam create-group --group-name Developers

# Add user to group
aws iam add-user-to-group --user-name developer-john --group-name Developers

# Attach policy to group
aws iam attach-group-policy --group-name Developers --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

IAM Policies

IAM policies are JSON documents that define permissions. They specify which actions are allowed or denied on which AWS resources.

Policy Types:
- AWS Managed: Created and managed by AWS
- Customer Managed: Created by you, reusable
- Inline: 1:1 relationship with an entity (not recommended)

🎯 Key Points

✓ Effect: Allow or Deny
✓ Action: Allowed/denied operations
✓ Resource: Specific AWS resources (ARN)
✓ Condition: Optional conditions to apply policy
✓ Principal: Who can assume the role (in trust policies)

💻 Basic IAM policy structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

💻 Example policy for S3 read-only access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

IAM Roles

An IAM role is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. Unlike a user, a role is designed to be assumed by anyone who needs it.

Common Use Cases:
- AWS Services: EC2 accessing S3, Lambda accessing DynamoDB
- Cross-Account Access: Account A accessing resources in Account B
- Federation: External users (Google, SAML) accessing AWS
- Temporary Users: Time-limited access

Why use roles instead of credentials?
- Temporary credentials that rotate automatically
- No need to manually manage/rotate Access Keys
- More secure: no long-term credential exposure

🎯 Key Points

✓ Roles don't have long-term credentials
✓ Provides temporary credentials (STS)
✓ Can be assumed by users, services, or applications
✓ Trust policy defines who can assume the role
✓ Permission policy defines what the role can do

💻 Trust policy allowing EC2 to assume the role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

💻 Creating a role for EC2

# Create a role
aws iam create-role --role-name EC2-S3-ReadOnly-Role --assume-role-policy-document file://trust-policy.json

# Attach permission policy
aws iam attach-role-policy --role-name EC2-S3-ReadOnly-Role --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Create instance profile (required for EC2)
aws iam create-instance-profile --instance-profile-name EC2-S3-Profile

# Associate role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name EC2-S3-Profile --role-name EC2-S3-ReadOnly-Role

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security by requiring users to provide two or more verification factors to access AWS.

MFA Types:
- Virtual MFA: Apps like Google Authenticator, Authy, Microsoft Authenticator
- Hardware MFA: Physical devices like YubiKey
- U2F Security Key: USB keys like YubiKey

When to use MFA:
- ALWAYS on the root user
- Users with administrative permissions
- Users with access to sensitive data
- AWS Console access

🎯 Key Points

✓ MFA combines something you know (password) + something you have (token)
✓ Protects against password compromise
✓ Virtual MFA is free and easy to set up
✓ You can enforce MFA through IAM policies

💻 Policy that enforces MFA for all actions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

IAM Best Practices

Following IAM best practices is crucial for maintaining a secure AWS account.

Top 10 Best Practices:

1. Lock down root user: Enable MFA and don't use root for daily tasks
2. Principle of least privilege: Grant only necessary permissions
3. Use groups: Assign permissions to groups, not individual users
4. Managed policies: Use managed policies instead of inline
5. Roles for applications: Use IAM roles, not hardcoded credentials
6. Rotate credentials: Rotate access keys and passwords regularly
7. Enable MFA: Especially for privileged users
8. Use conditions: Restrict access by IP, time, MFA, etc.
9. Audit permissions: Review policies with IAM Access Analyzer
10. Monitor activity: Use CloudTrail to audit API calls

🎯 Key Points

✓ Security is shared responsibility
✓ Use AWS Security Hub for recommendations
✓ Implement separation of duties
✓ Document your policies and roles
✓ Use tags to organize IAM resources

← Back to AWS-SAA-C03