IAM Cross-Account Role Assumptions

IAM cross-account role assumption is a security mechanism that allows a principal (user, group, or service) in one AWS account to obtain temporary credentials to access resources in another AWS account. This is achieved by assuming an IAM role that exists in the target account. The role defines what actions the assuming principal can perform on which resources. This model eliminates the need to create IAM users across multiple accounts or share long-term access keys, enhancing security and auditability.

In multi-account AWS environments, organizations often isolate workloads for security, billing, or organizational boundaries. However, there are legitimate needs for cross-account access, such as:

Cross-account roles are the recommended AWS best practice for these scenarios because they provide temporary, scoped credentials that can be revoked at any time by modifying the role's trust policy.

The process of assuming a cross-account role uses the AWS Security Token Service (STS). Here is the step-by-step mechanism:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/CrossAccountRole"
    }
  ]
}

To configure cross-account role assumption:

To verify, the user in Account A can use the AWS CLI:

aws sts assume-role --role-arn "arn:aws:iam::222222222222:role/CrossAccountRole" --role-session-name "TestSession"

The output includes temporary credentials. The user can then export them as environment variables and make API calls.

A large enterprise with 50 AWS accounts for different business units (production, development, marketing) needs a single security team to audit all accounts. The security team has a dedicated 'Security' AWS account. In each member account, an IAM role named 'SecurityAuditRole' is created with a trust policy allowing the Security account's root user to assume it. The role is attached to a managed policy like 'SecurityAuditPolicy' that grants read-only access to CloudTrail, Config, S3 bucket policies, and IAM. The security team uses AWS CLI scripts that loop through all account IDs, assume the role, and collect audit data. To handle scale, they use AWS Organizations and the organizations:ListAccounts API to dynamically discover accounts. Performance considerations: Each AssumeRole call takes ~1-2 seconds, so for 50 accounts, the script completes in under 2 minutes. Misconfiguration: If the trust policy accidentally includes "Principal": "*", any AWS account could assume the role, leading to a data breach. The fix is to restrict the principal to the specific security account ARN.

A company uses a data lake account to aggregate data from multiple production accounts. Each production account has an S3 bucket with raw data. The data lake account has an S3 bucket for staging. The data lake account creates a role named 'DataIngestionRole' with permissions to read from the production buckets and write to the staging bucket. The trust policy allows the production accounts' root users to assume this role. The production accounts have a Lambda function that triggers daily, assumes the DataIngestionRole, and copies new data to the staging bucket. This avoids storing long-term keys in Lambda environment variables. Scale: The role may be assumed hundreds of times per day. The role's permission policy uses resource ARNs to restrict access to specific buckets. Common issue: If the Lambda function's execution role in the production account does not have sts:AssumeRole permission on the DataIngestionRole ARN, the assumption fails. The engineer must attach an inline policy to the Lambda role.

An organization uses a backup account to store EBS snapshots and RDS backups from all other accounts. In each source account, an IAM role 'BackupRole' is created with permissions to create snapshots and copy them to the backup account. The trust policy allows the backup account's backup automation role to assume it. The backup account runs a scheduled job that assumes the BackupRole in each source account, creates a snapshot, and copies it to a central AMI or snapshot in the backup account. This design ensures that even if a source account is compromised, the backups remain safe in a separate account. Misconfiguration: If the role's permission policy does not include ec2:CopySnapshot to the backup account, the copy fails. The engineer must ensure the role has permissions to copy to the backup account's resources. Also, the backup account must have a resource-based policy on the destination snapshots to allow the source role to copy.