Skip to main content

Security and Identity Access Management (IAM)

Now that you've learned about AWS core services and networking, it's time to address one of the most critical aspects of cloud computing: security. In this lesson, we'll explore AWS Identity and Access Management (IAM), the service that controls who can access what in your AWS environment.

Learning Goals:

  • Understand IAM concepts and components
  • Create and manage IAM users, groups, and roles
  • Write and test IAM policies
  • Implement security best practices

What is IAM?​

AWS Identity and Access Management (IAM) is the foundation of AWS security. It enables you to manage access to AWS services and resources securely. Think of IAM as the gatekeeper that determines who can enter your AWS environment and what they can do once they're inside.

Key IAM components:

  • Users: Individual people or applications that need AWS access
  • Groups: Collections of users with similar permissions
  • Roles: Temporary credentials for AWS services or cross-account access
  • Policies: JSON documents that define permissions

IAM Users and Groups​

Creating Your First IAM User​

Never use your AWS root account for daily tasks. Instead, create individual IAM users:

Create IAM user via AWS CLI
aws iam create-user --user-name "alice-developer"
IAM User creation response
{
    "User": {
        "UserName": "alice-developer",
        "UserId": "AIDASAMPLEUSERID",
        "Arn": "arn:aws:iam::123456789012:user/alice-developer",
        "CreateDate": "2024-01-15T10:00:00Z"
    }
}

Organizing Users with Groups​

Groups make permission management scalable:

Create developer group
aws iam create-group --group-name "Developers"
Add user to group
aws iam add-user-to-group --user-name "alice-developer" --group-name "Developers"
tip

Create groups based on job functions (Developers, Admins, ReadOnly) rather than individual users. This simplifies permission management as team members change roles.

IAM Policies: The Heart of Access Control​

IAM policies are JSON documents that specify what actions are allowed or denied on which resources.

Understanding Policy Structure​

Example S3 read-only policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}

Let's break this down:

  • Effect: "Allow" or "Deny"
  • Action: Specific API operations
  • Resource: Which AWS resources this applies to

Creating and Attaching Policies​

# Create the policy
aws iam create-policy \
    --policy-name "S3ReadOnlyAccess" \
    --policy-document file://s3-readonly-policy.json

# Attach to group
aws iam attach-group-policy \
    --group-name "Developers" \
    --policy-arn "arn:aws:iam::123456789012:policy/S3ReadOnlyAccess"

IAM Roles for Service Access​

Roles provide temporary credentials for AWS services to access other services. This is more secure than storing long-term access keys.

Creating an EC2 Role​

ec2-s3-access-role.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
Create and attach role
# Create the role
aws iam create-role \
    --role-name "EC2S3AccessRole" \
    --assume-role-policy-document file://ec2-s3-access-role.json

# Attach S3 access policy
aws iam attach-role-policy \
    --role-name "EC2S3AccessRole" \
    --policy-arn "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
warning

Never hardcode AWS credentials in your application code. Use IAM roles for EC2 instances, Lambda functions, and other AWS services that need to access AWS resources.

Testing IAM Policies​

Before deploying policies, test them using IAM Policy Simulator or the CLI:

Test policy permissions
aws iam simulate-principal-policy \
    --policy-source-arn "arn:aws:iam::123456789012:user/alice-developer" \
    --action-names "s3:GetObject" "s3:PutObject" \
    --resource-arns "arn:aws:s3:::example-bucket/important-file.txt"

Security Best Practices​

  1. Enable MFA: Require multi-factor authentication for all users
  2. Use Roles: Prefer roles over long-term access keys
  3. Least Privilege: Grant only necessary permissions
  4. Regular Audits: Review permissions and access patterns
  5. Rotate Credentials: Regularly rotate access keys
Enable MFA for user
aws iam create-virtual-mfa-device \
    --virtual-mfa-device-name "alice-mfa" \
    --outfile "qr-code.png" \
    --bootstrap-method QRCodePNG

Common Pitfalls​

  • Overly Permissive Policies: Using "Resource": "*" or "Action": "*" without proper constraints
  • Hardcoded Credentials: Storing access keys in code repositories
  • Root Account Usage: Using root account for daily operations
  • Neglecting MFA: Not enabling multi-factor authentication
  • Policy Complexity: Creating policies that are too complex to maintain and audit

Summary​

IAM is your first line of defense in AWS security. Remember these key points:

  • Create individual IAM users instead of sharing root credentials
  • Use groups to manage permissions for teams
  • Implement the principle of least privilege in all policies
  • Prefer IAM roles over access keys for service-to-service communication
  • Always enable MFA for enhanced security

AWS IAM Fundamentals

What is the primary purpose of IAM roles?

Question 1/4