2.1.5. Cross-Account Access Patterns
First Principle: Cross-account access patterns enable secure, delegated access to resources in one AWS account from another, fostering flexibility and collaboration without sharing long-lived credentials.
In a multi-account strategy, it's often necessary for users or services in one AWS account to access resources in a different AWS account. This needs to be done securely to maintain isolation and adhere to the Principle of Least Privilege.
Key Cross-Account Access Patterns:
- IAM Roles for Cross-Account Access:
- Concept: The most secure and recommended way. An IAM role is created in the target account (where the resources reside) that grants specific permissions. This role includes a trust policy that specifies which principals (IAM users or roles) from the source account are allowed to assume it.
- Mechanism: The user or service in the source account "assumes" this role using AWS Security Token Service (STS) to get temporary credentials for the target account.
- Benefits: No long-lived credentials shared, temporary permissions, easy to audit, scalable for multiple accounts.
- Resource-Based Policies:
- Concept: Attaching a policy directly to a resource (e.g., an Amazon S3 bucket policy) to explicitly grant permissions to an IAM principal in another account.
- Benefits: Useful for controlling access to a single resource.
- Note: If both an identity-based policy and a resource-based policy apply, both must grant the permission for access to be allowed.
Scenario: A central security team needs to audit S3 bucket policies and EC2 Security Group rules in various application-specific AWS accounts. They need secure, temporary access from their central security account to these other accounts.
Reflection Question: How do cross-account access patterns, specifically using IAM Roles and AWS Security Token Service (STS), fundamentally enable secure, delegated access to resources in one AWS account from another, fostering collaboration without sharing long-lived credentials?