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.

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

Loading diagram...

⚠️ 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?