Mastering IAM Role Assumption & AWS STS

This guide covers the mechanisms, security benefits, and implementation patterns for assuming IAM roles using the AWS Security Token Service (STS), a core competency for the AWS Certified Developer - Associate (DVA-C02) exam.

Learning Objectives

By the end of this study guide, you should be able to:

• Explain how AWS STS generates and manages temporary security credentials.
• Differentiate between Trust Policies and Identity-based Policies.
• Configure EC2 Instance Profiles to eliminate hardcoded credentials.
• Implement Cross-Account Access using delegation patterns.
• Understand the limitations and constraints of Role Chaining.

Key Terms & Glossary

• STS (Security Token Service): A global AWS service that grants limited-privilege, temporary credentials to users/services.
• AssumeRole: An API operation that returns temporary credentials (Access Key ID, Secret Access Key, and Session Token).
• Trust Policy: A JSON document attached to a role defining which principals (users, services, or accounts) are allowed to assume it.
• Instance Profile: A container for an IAM role that allows an EC2 instance to automatically receive temporary credentials.
• Trusted Account: The account containing the user/identity that needs access.
• Trusting Account: The account containing the resource (e.g., S3 bucket) and the IAM Role.

The "Big Idea"

In cloud security, long-term credentials are a liability. If a developer hardcodes an Access Key into an application, a single leak compromises the account indefinitely until the key is manually rotated.

IAM Role Assumption flips this script: instead of "having" a key, an entity "requests" a temporary session. This reduces the blast radius of a credential leak because the session automatically expires, and no sensitive secrets are stored in the application source code.

Formula / Concept Box

Hierarchical Outline

1. Identity Federation & STS
   • Mechanism: STS generates credentials based on attached policies.
   • Expiration: Credentials last from minutes to hours; once expired, they are invalid.
2. EC2 Instance Roles
   • Instance Profiles: Acts as the bridge between the EC2 and the IAM Role.
   • Security: Removes the need for ~/.aws/credentials files on servers.
3. Cross-Account Delegation
   • Step 1: Define the role in the Trusting Account.
   • Step 2: Define the Trust Policy (Allow Account A to assume).
   • Step 3: Grant sts:AssumeRole permissions in the Trusted Account.
4. Role Chaining
   • Occurs when Role A assumes Role B.
   • Constraint: Session duration is strictly limited to 1 hour.

Visual Anchors

Flow: EC2 Instance Profile Pattern

Cross-Account Access Logic

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum width=3cm, minimum height=1cm, align=center}]

% Define accounts \node (accA) {\textbf{Account A (Trusted)}\Developer Identity}; \node (accB) [right=3cm of accA] {\textbf{Account B (Trusting)}\Target Resource (S3)};

% Define internal components \node (policyA) [below=1cm of accA] {Permission Policy$sts:AssumeRole)}; \node (roleB) [below=1cm of accB] {IAM Role$S3 Access)}; \node (trustB) [below=0.5cm of roleB] {Trust Policy$Allow Account A)};

% Draw paths \draw [->, thick] (accA) -- (policyA); \draw [->, thick] (policyA) -- node[above] {1. sts:AssumeRole} (roleB); \draw [->, thick] (roleB) -- (trustB); \draw [->, dashed] (roleB) -- node[below] {2. Returns Temp Creds} (accA);

\end{tikzpicture}

Definition-Example Pairs

• Term: Trust Policy

  • Definition: A resource-based policy attached to an IAM role that defines which principals can assume the role.
  • Example: A Lambda function in Account 111122223333 needs to write to DynamoDB in Account 444455556666. The role in Account 444455556666 must have a Trust Policy listing the Lambda's ARN as a trusted principal.

• Term: Role Chaining

  • Definition: The process of using a set of temporary credentials to assume yet another role.
  • Example: An administrator logs into a "Jump Account" role and then assumes a "Production Manager" role in a different account to perform maintenance.

Worked Examples

Scenario: Configuring S3 Access for an EC2-hosted App

The Problem: A developer needs their web app on EC2 to download images from S3 without putting secret keys in the app.config file.

The Solution:

1. Create IAM Role: Create a role named S3-ReadOnly-Role.
2. Attach Permissions: Attach the AmazonS3ReadOnlyAccess managed policy.
3. Define Trust: Ensure the Trust Policy allows ec2.amazonaws.com to assume the role.
4. Create Instance Profile: Attach the S3-ReadOnly-Role to an Instance Profile.
5. Assign to EC2: Go to the EC2 console, select the instance, and choose "Modify IAM Role." Pick the new profile.
6. Verification: Run aws s3 ls on the EC2 terminal. It works without any aws configure setup because the SDK automatically fetches tokens from the Instance Metadata Service.

Checkpoint Questions

1. True or False: IAM Roles use long-term credentials like usernames and passwords. (Answer: False. They use temporary credentials managed by STS.)
2. What is the default duration for a session when calling AssumeRole? (Answer: 1 hour.)
3. If you are performing "Role Chaining," what is the maximum session duration you can request? (Answer: 1 hour.)
4. Which policy defines who can assume a role? (Answer: The Trust Policy.)
5. Why is using Instance Profiles better than hardcoding keys? (Answer: It prevents credential theft from source code and removes the burden of manual key rotation.)

[!IMPORTANT] When configuring cross-account access, remember: permissions are required in both accounts. The trusting account must allow the access, and the trusted account must give the user permission to switch to that role.