Cross-account access in AWS is a security feature that allows users, roles, or services in one AWS account to access resources in another AWS account. This capability is essential for organizations managing multiple AWS accounts, enabling centralized management while maintaining security boundaries…Cross-account access in AWS is a security feature that allows users, roles, or services in one AWS account to access resources in another AWS account. This capability is essential for organizations managing multiple AWS accounts, enabling centralized management while maintaining security boundaries.
The primary mechanism for implementing cross-account access is through IAM roles with trust policies. When Account A needs to access resources in Account B, you create an IAM role in Account B with a trust policy that specifies Account A as a trusted entity. Users or services in Account A can then assume this role to gain temporary credentials for accessing Account B's resources.
Key components of cross-account access include:
1. Trust Policy: Defines which principals (users, roles, or accounts) can assume the role. This policy is attached to the role being assumed.
2. Permissions Policy: Specifies what actions the assumed role can perform on resources in the target account.
3. External ID: An optional security measure that adds an extra layer of protection against confused deputy attacks when third parties access your account.
4. Resource-Based Policies: Some AWS services like S3 and KMS support resource-based policies that can grant cross-account access to specific resources.
Best practices for cross-account access include:
- Apply the principle of least privilege by granting only necessary permissions
- Use external IDs when working with third-party access
- Enable CloudTrail logging to monitor cross-account activities
- Regularly audit and review cross-account access configurations
- Implement MFA requirements for assuming sensitive roles
AWS Organizations and Service Control Policies (SCPs) can provide additional governance over cross-account access patterns. AWS Resource Access Manager (RAM) offers another approach for sharing specific resources across accounts within an organization, simplifying resource sharing while maintaining security controls.
Cross-Account Access in AWS
What is Cross-Account Access?
Cross-account access is an AWS security feature that allows resources, users, or services in one AWS account to access resources in another AWS account. This is essential for organizations that operate multiple AWS accounts for different environments (development, staging, production), business units, or security boundaries.
Why is Cross-Account Access Important?
1. Security Isolation: Organizations can maintain separate accounts for different purposes while still enabling controlled collaboration between them.
2. Centralized Management: A central security or logging account can collect data from multiple accounts.
3. Least Privilege: Cross-account access allows granting temporary, limited permissions rather than sharing long-term credentials.
4. Compliance: Maintaining separate accounts helps meet regulatory requirements while enabling necessary resource sharing.
How Cross-Account Access Works
Method 1: IAM Roles (AssumeRole) - The trusting account creates an IAM role with a trust policy specifying the trusted account - The trusted account's users or services assume the role using AWS STS (Security Token Service) - Temporary credentials are issued with the permissions defined in the role
Method 2: Resource-Based Policies - Some AWS services support resource-based policies (S3 buckets, SNS topics, SQS queues, KMS keys) - The resource policy specifies which external accounts or principals can access the resource - No role assumption is required
Method 3: AWS Organizations and Service Control Policies (SCPs) - Organizations can use AWS Organizations to manage cross-account access at scale - SCPs define permission boundaries across accounts
Key Components for IAM Role-Based Cross-Account Access:
1. Trust Policy: Attached to the role, defines WHO can assume the role (the trusted account/principal)
2. Permissions Policy: Attached to the role, defines WHAT actions the role can perform
3. External ID: An optional security measure to prevent confused deputy attacks when third parties assume roles
Common Use Cases: - Centralized logging to a security account - Cross-account S3 bucket access - Shared services accounts - Third-party vendor access - Cross-account AWS Config or CloudTrail aggregation
Exam Tips: Answering Questions on Cross-Account Access
Tip 1: When a question mentions sharing resources between accounts, think IAM roles first. Role assumption via STS is the preferred and most secure method.
Tip 2: Remember the difference between trust policies (who can assume) and permissions policies (what they can do). Questions often test this distinction.
Tip 3: For S3, Lambda, SNS, SQS, and KMS, resource-based policies can grant cross-account access. Know which services support this.
Tip 4: External IDs are used when granting access to third parties to prevent the confused deputy problem. Look for this in scenarios involving external vendors.
Tip 5: If a question asks about temporary credentials for cross-account access, the answer involves AWS STS and the AssumeRole API.
Tip 6: For centralized logging or security monitoring across accounts, expect answers involving cross-account roles with CloudWatch, CloudTrail, or Config.
Tip 7: When MFA is mentioned with cross-account access, remember that trust policies can include conditions requiring MFA authentication before role assumption.
Tip 8: Know the maximum session duration for assumed roles (default 1 hour, configurable up to 12 hours).
Tip 9: AWS Organizations with SCPs provides governance over cross-account permissions at the organizational level.
Tip 10: For questions about cross-account KMS key usage, both the key policy AND IAM policy in the calling account must allow the action.