Evaluating Cross-Account Access Management

Cross-account access management is a cornerstone of complex AWS architectures. It allows organizations to share resources and centralize security while maintaining the isolation benefits of a multi-account strategy.

Learning Objectives

• Distinguish between Trusting Accounts and Trusted Accounts.
• Configure IAM role Trust Policies for cross-account principals.
• Evaluate the trade-offs between Resource-based Policies and Identity-based Access Delegation.
• Understand the role of STS (Security Token Service) in generating temporary credentials.
• Determine the appropriate use of ABAC (Attribute-Based Access Control) for federated cross-account access.

Key Terms & Glossary

• Trusting Account: The account that owns the resource and defines who is allowed to access it.
• Trusted Account: The account containing the principal (user/role) that needs to access resources in another account.
• Trust Policy: A resource-based policy attached to an IAM role that defines which principals can assume the role.
• STS (Security Token Service): The AWS service that provides temporary security credentials for IAM users or federated users.
• ABAC (Attribute-Based Access Control): An authorization strategy that defines permissions based on attributes (tags), rather than static roles.
• SCIM (System for Cross-domain Identity Management): A protocol used to automate the exchange of user identity information between identity domains.

The "Big Idea"

In a complex organization, security is achieved through Access Delegation. Instead of creating duplicate IAM users in every account, we establish a Trust Relationship. A user in a "Developer Account" (Trusted) can assume a role in a "Production Account" (Trusting) to perform specific tasks. This minimizes long-lived credentials and centralizes identity management.

Formula / Concept Box

[!IMPORTANT] For cross-account access to succeed, the Trust Policy in the Trusting Account must ALLOW the access, and the Identity Policy in the Trusted Account must also ALLOW the sts:AssumeRole action.

Hierarchical Outline

1. IAM Roles as a Bridge
   • Dual Nature: Roles act as both an identity (when used) and a resource (when being assumed).
   • Trust Policies: Define who can assume the role (Resource-based policy for the role).
   • Permissions Policies: Define what the role can do (Identity-based policy for the role).
2. Cross-Account Mechanics
   • Account A (Trusting): Creates the role and defines the trust policy.
   • Account B (Trusted): Contains the user who calls sts:AssumeRole.
3. Scaling with Federation
   • AWS IAM Identity Center (SSO): Best for organization-wide federation.
   • Direct IAM Federation: Best for individual account-to-IdP links.
   • ABAC Strategy: Using session tags passed via SAML/OIDC to manage permissions dynamically.

Visual Anchors

Cross-Account Trust Flow

Relationship Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, minimum width=2.5cm, minimum height=1cm, align=center}] \node (Trusted) {Trusted Account \ (Account B)}; \node (Trusting) [right=3cm of Trusted] {Trusting Account \ (Account A)}; \node (Resource) [below=1.5cm of Trusting] {AWS Resource \ (S3, RDS, etc.)};

\draw[->, thick] (Trusted) -- node[above] {sts:AssumeRole} (Trusting); \draw[->, thick] (Trusting) -- node[right] {Access} (Resource);

\node[draw=none, below=0.1cm of Trusted] {\tiny Holds the Principal}; \node[draw=none, below=0.1cm of Trusting] {\tiny Holds the Role}; \end{tikzpicture}

Definition-Example Pairs

• Trust Policy: A JSON policy document attached to a role that specifies which accounts or users can assume it.
  • Example: Account A (Storage) allows arn:aws:iam::123456789012:root (Account B) to assume the CrossAccountAdmin role.
• Session Tags: Key-value pairs passed during role assumption to enable ABAC.
  • Example: A developer logs in via Okta with a Project: Alpha tag; AWS uses this tag to grant access only to S3 buckets tagged Project: Alpha.

Worked Examples

Scenario: Sharing a Central S3 Bucket

Goal: User DevUser in Account 2222 needs to read logs in Account 1111.

1. In Account 1111 (Trusting Account):

   • Create a role named LogReaderRole.
   • Trust Policy:
     jsonCopy

     { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::2222:user/DevUser" }, "Action": "sts:AssumeRole" }] }
   • Permissions Policy: Attach AmazonS3ReadOnlyAccess to this role.

2. In Account 2222 (Trusted Account):

   • Attach a policy to DevUser allowing them to call sts:AssumeRole on the ARN of LogReaderRole in Account 1111.

Checkpoint Questions

1. Why is using an IAM Role preferred over a Resource-based policy for services like EC2?
2. What is the specific STS API call used to gain temporary credentials for a role?
3. In a cross-account scenario, which account pays for the resources used by the assumed role?
4. What is the difference between SCIM and SAML in the context of IAM Identity Center?

Muddy Points & Cross-Refs

• Role Chaining: You can assume a role from a role, but the session is limited to a maximum of 1 hour by default and cannot be extended.
• Resource-based Policy Support: Not all services support resource-based policies (e.g., S3, SNS, and SQS do; EC2 does not). If the service doesn't support it, you must use IAM roles for cross-account access.
• Confused Deputy: Remember to use ExternalId in trust policies when allowing third-party (SaaS) access to your account to prevent the confused deputy security risk.

Comparison Tables