Cross-account role assumption is a powerful AWS Identity and Access Management (IAM) feature that enables secure access to resources across different AWS accounts. This mechanism is essential for organizations managing multiple AWS accounts and needing to share resources securely.
The process invo…Cross-account role assumption is a powerful AWS Identity and Access Management (IAM) feature that enables secure access to resources across different AWS accounts. This mechanism is essential for organizations managing multiple AWS accounts and needing to share resources securely.
The process involves three key components: a trusting account (the account containing resources to be accessed), a trusted account (the account whose users need access), and an IAM role with appropriate permissions.
Here's how it works:
1. **Create an IAM Role**: In the trusting account, create an IAM role with a trust policy that specifies which AWS account (or specific users/roles) can assume this role. The trust policy defines the principal allowed to call sts:AssumeRole.
2. **Attach Permissions**: Attach an IAM policy to the role defining what actions the assuming entity can perform on resources in the trusting account.
3. **Grant AssumeRole Permission**: In the trusted account, ensure users or roles have permission to call sts:AssumeRole for the target role ARN.
4. **Assume the Role**: Users call the AWS Security Token Service (STS) AssumeRole API, providing the role ARN. STS returns temporary security credentials (access key, secret key, and session token).
5. **Access Resources**: Use the temporary credentials to make API calls to resources in the trusting account.
Key benefits include:
- **Enhanced Security**: No need to share long-term credentials between accounts
- **Temporary Access**: Credentials expire automatically (default 1 hour, configurable up to 12 hours)
- **Audit Trail**: All role assumptions are logged in CloudTrail
- **Principle of Least Privilege**: Roles can be scoped to specific permissions
Common use cases include centralized security management, shared services architectures, and third-party vendor access. External IDs can be added to trust policies for additional security when granting access to external entities, preventing confused deputy attacks.
Cross-Account Role Assumption
What is Cross-Account Role Assumption?
Cross-account role assumption is an AWS Identity and Access Management (IAM) feature that allows users or services in one AWS account to temporarily access resources in another AWS account. This is accomplished through IAM roles that establish a trust relationship between accounts, enabling secure delegation of permissions across organizational boundaries.
Why is Cross-Account Role Assumption Important?
• Security: Eliminates the need to share long-term credentials between accounts • Centralized Management: Allows organizations to manage multiple AWS accounts while maintaining access control • Least Privilege: Temporary credentials expire automatically, reducing security risks • Compliance: Enables proper separation of environments (dev, staging, production) while allowing necessary access • Audit Trail: All cross-account access is logged in CloudTrail for both accounts
How Cross-Account Role Assumption Works
Step 1: Create an IAM Role in the Target Account The target account (Account B) creates an IAM role with: • A trust policy specifying which principals from the source account (Account A) can assume the role • A permissions policy defining what actions the role can perform
Step 2: Configure the Trust Policy The trust policy in Account B must include: • The AWS account ID of Account A • Optionally, specific IAM users, roles, or conditions
Step 3: Grant Permission to Assume the Role Account A must grant its users or roles permission to call sts:AssumeRole on the target role ARN
Step 4: Assume the Role The user or service calls AWS STS AssumeRole API with the role ARN to receive temporary security credentials
Step 5: Use Temporary Credentials The returned credentials (access key, secret key, session token) are used to make API calls to Account B resources
Key Components
• AWS Security Token Service (STS): The service that provides temporary credentials • Trust Policy: Defines who can assume the role (the Principal element) • Permissions Policy: Defines what the role can do once assumed • External ID: An optional identifier for enhanced security when third parties assume roles • Session Duration: Configurable from 15 minutes to 12 hours
Common Use Cases
• Development teams accessing production resources for troubleshooting • Third-party vendors accessing your AWS resources securely • Centralized logging or monitoring across multiple accounts • AWS Organizations member accounts accessing shared services • CI/CD pipelines deploying to multiple accounts
Exam Tips: Answering Questions on Cross-Account Role Assumption
1. Identify the Two Accounts: Always determine which account is the trusting account (has the role) and which is the trusted account (assumes the role)
2. Trust Policy vs Permissions Policy: Remember that trust policies control WHO can assume the role, while permissions policies control WHAT they can do
3. STS:AssumeRole is Key: When you see scenarios requiring cross-account access, look for answers involving sts:AssumeRole
4. External ID: If the question mentions third-party access or the confused deputy problem, External ID is likely part of the solution
5. Temporary Credentials: Cross-account access uses temporary credentials, not long-term access keys - this is a security best practice
6. Both Sides Need Configuration: The role must exist in the target account AND the source account must have permission to assume it
7. Resource-Based vs Identity-Based: Cross-account role assumption combines trust policies (resource-based) with identity policies
8. CloudTrail Logging: Both accounts will have CloudTrail entries - the source account logs the AssumeRole call, the target account logs the subsequent API calls
9. Eliminate Wrong Answers: Options suggesting sharing access keys or creating IAM users in multiple accounts are typically incorrect for cross-account scenarios
10. Look for ARN References: Correct answers will often include the full ARN of the role being assumed