How IAM Role Assumption Delegates Temporary Session Keys

Introduction

AWS Identity and Access Management (IAM) has two credential types: long-term credentials (access keys tied to IAM users — persistent, risky if leaked) and temporary credentials (from AWS STS AssumeRole — short-lived, automatically rotating, audited). The AWS security best practice is to never use long-term credentials in production code. Instead, EC2 instances, Lambda functions, and ECS tasks assume IAM roles and receive temporary credentials from the AWS Security Token Service (STS). These credentials expire after 15 minutes to 12 hours, dramatically reducing the blast radius of a credential leak.

Step-by-Step: How Role Assumption Works

flowchart TD
    A["1. Role Anatomy"]
    B["2. The AssumeRole API Call"]
    C["3. Instance Profiles (EC2 Automatic Assumption)"]
    D["4. Cross-Account Access"]
    E["5. Session Policies"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Role Anatomy — Trust Policy vs. Permission Policy

An IAM role has two separate policy documents:

Trust Policy (who can assume this role):

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/CI-Pipeline",
      "Service": "ec2.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {"sts:ExternalId": "unique-secret-xyz"}
    }
  }]
}

Permission Policy (what the role can do after assumption):

{
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::prod-bucket/*"
  }]
}

Step 2: The AssumeRole API Call

# CLI role assumption
aws sts assume-role   --role-arn "arn:aws:iam::ACCOUNT_ID:role/DataProcessor"   --role-session-name "ProcessorSession-$(date +%s)"   --duration-seconds 3600   --external-id "unique-secret-xyz"

# Returns:
{
  "Credentials": {
    "AccessKeyId": "ASIA...",          # Temporary (starts with ASIA)
    "SecretAccessKey": "wJalrX...",
    "SessionToken": "AQoDYXdzE...",    # Required for all API calls
    "Expiration": "2024-03-15T15:23:11Z"
  }
}

Step 3: Instance Profiles (EC2 Automatic Assumption)

EC2 instances don’t call AssumeRole manually. The instance metadata service (IMDS) handles it transparently:

# Credentials auto-refreshed before expiry
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

# AWS SDK automatically fetches and refreshes from IMDS
import boto3
s3 = boto3.client('s3')  # No credentials needed — uses instance role

Step 4: Cross-Account Access

A role in Account B can allow Account A’s principals to assume it:

Account A (CI/CD Account): Role CI-Pipeline
  → AssumeRole → Account B: Role Deployer
     → Permission to deploy to Account B's ECS cluster

Trust Policy on Deployer role:
Principal: arn:aws:iam::ACCOUNT_A_ID:role/CI-Pipeline
Condition: ExternalId required (prevents confused deputy attack)

Step 5: Session Policies (Restricting Permissions at Assumption Time)

You can further restrict what a session can do below the role’s permissions:

aws sts assume-role   --role-arn "arn:aws:iam::123456789:role/Admin"   --role-session-name "ReadOnlySession"   --policy '{"Statement":[{"Effect":"Allow","Action":"s3:Get*","Resource":"*"}]}'
# Result: Session can only GetObject even though Admin role has full S3 access

Key Takeaways

• IAM roles issue temporary credentials (15 min–12 hr TTL) via AWS STS — far safer than long-term access keys.
• Roles have two separate policies: trust policy (who can assume) and permission policy (what they can do after assuming).
• Instance profiles automatically deliver credentials to EC2 via IMDS — the AWS SDK handles rotation transparently.
• Cross-account role assumption + External ID prevents the “confused deputy” attack where a third-party service is tricked into accessing your account.
• Session policies at assumption time let you grant a minimal subset of a role’s permissions — useful for CI/CD least-privilege patterns.