2.1.1.5. Cross-Account Access and AWS STS

2.1.1.5. Cross-Account Access and AWS STS

💡 First Principle: Cross-account access securely delegates permissions to resources in one AWS account to identities in another, fostering flexibility without sharing sensitive credentials.

Cross-account access enables users or services in one AWS account to access resources in a different AWS account. This is achieved by creating an IAM role in the target account (the account with the resources) that grants specific permissions and allows an IAM entity from the source account to assume it.

AWS Security Token Service (STS) is the web service that facilitates this by issuing temporary, limited-privilege credentials for IAM roles. When an IAM entity in one account assumes a role in another, STS provides a temporary set of credentials that are valid for a specified duration.

Key Aspects of Cross-Account Access:

• Delegation: Securely grant permissions to another account.
• "IAM Roles": Primary mechanism for cross-account access.
• "AWS STS": Issues temporary credentials.
• No Shared Credentials: Enhances security by avoiding long-term access key sharing.

The two halves of a cross-account role (both are required):

• Target account (B): an IAM role with a trust policy naming account A (or a specific principal in A), plus a permissions policy for the resources.
• Source account (A): an identity policy allowing the caller to call sts:AssumeRole on that role's ARN. The application calls AssumeRole, then signs its requests with the returned temporary credentials. In the console the same mechanism is Switch Role: a signed-in user assumes a role in another account without signing out and back in.
• Sharing the resource instead of the access: AWS Resource Access Manager (RAM) shares certain resources themselves — e.g. VPC subnets, Transit Gateways, Route 53 Resolver rules — with other AWS accounts or with OUs in your organization (VPC subnets only within the organization), so they can use them without peering or duplicating them. Standard cross-account S3 bucket access is granted with a bucket policy (see 2.1.1.7), not through RAM.

Scenario: A central auditing team needs to periodically access log data stored in S3 buckets across multiple development accounts. They need a secure way to do this without managing separate IAM users in each development account.

Visual: Cross-Account Access with AWS STS

⚠️ Common Pitfall: Granting overly broad permissions to the IAM role in the target account. Always apply the principle of least privilege.

Key Trade-Offs:

• Security (Temporary Credentials) vs. Simplicity (Shared Long-Term Keys): Using temporary credentials via STS and roles is more secure than sharing long-term access keys but adds a small layer of complexity.

Reflection Question: How does temporary credential usage via AWS STS when assuming cross-account roles fundamentally enhance security compared to long-term credential sharing in multi-account setups?