> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Cross Account Roles and How to Assume Them

> Guide showing how a user in one AWS account can assume a role in another to access S3, including trust policies, role permissions, and caller policies allowing stsAssumeRole

This guide demonstrates how a user in one AWS account (Account B) can assume a role in another AWS account (Account A) to access Amazon S3 resources. It covers the required trust policy, role permission policy, and the user policy that allows `sts:AssumeRole`. This pattern is commonly used for cross-account access, least-privilege delegation, and temporary credential issuance.

Key concepts: cross-account role, trust policy (`Principal` + `sts:AssumeRole`), permission policy (what the role can do), and the caller policy that permits `sts:AssumeRole`.

## Environment (accounts & principals)

| Account | Role / User | Identifier |
| - | -: | - |
| Account A (role owner) | Role to create | `CrossAccountS3ReadRole` — Account ID: `635573991785` |
| Account B (caller) | IAM user | `arnold2` — Account ID: `466456867028` |

## Overview / Flow

1. In Account A, create an IAM role with a trust policy that explicitly allows the user `arnold2` in Account B to assume it.
2. Attach an S3 read-only permission policy to the role (e.g., `AmazonS3ReadOnlyAccess`).
3. In Account B, attach an inline or managed policy to `arnold2` allowing `sts:AssumeRole` on the role ARN in Account A.
4. The user `arnold2` can then assume the role via Console (Switch Role), CLI, or SDK and perform actions permitted by the role (read-only S3 in this demo).

When creating cross-account trust, lock the trust policy to the smallest set of principals necessary. Using explicit ARNs (like `arn:aws:iam::466456867028:user/arnold2`) is safer than wildcards.

***

## Step 1 — Create the cross-account role in Account A

1. Sign in to Account A (`635573991785`).
2. Open the IAM console → Roles → Create role.
3. Choose to create a role with a custom trust policy (replace the default). The trust policy must allow the specific principal (the user `arnold2` in Account B) to call `sts:AssumeRole`.

Example trust policy (paste into the trust policy editor):

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::466456867028:user/arnold2"
      },
      "Action": "sts:AssumeRole",
      "Sid": ""
    }
  ]
}
```

This policy grants the IAM user `arnold2` in Account B permission to assume the role.

## Step 2 — Attach permissions to the role

* After creating the role and configuring the trust policy, attach a permission policy granting S3 read access. For this demo we attach the AWS managed policy `AmazonS3ReadOnlyAccess`.
* Give the role a descriptive name such as `CrossAccountS3ReadRole` and finish role creation.

Note: You can alternatively create a custom inline policy for the role if you need to restrict access to specific buckets or prefixes.

***

## Step 3 — Give the user in Account B permission to assume the role

In Account B (`466456867028`) attach an inline policy (or a managed policy) to the IAM user `arnold2` that allows `sts:AssumeRole` on the role ARN in Account A. Example policy:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::635573991785:role/CrossAccountS3ReadRole"
    }
  ]
}
```

This policy grants `arnold2` the ability to call `AssumeRole` on `CrossAccountS3ReadRole`.

Optional: If you prefer CLI verification, the user can call `aws sts assume-role` once they have this permission:

Example (run as `arnold2` with regular credentials configured):

```bash theme={null}
aws sts assume-role \
  --role-arn arn:aws:iam::635573991785:role/CrossAccountS3ReadRole \
  --role-session-name arnold2-session
```

The output returns temporary credentials (`AccessKeyId`, `SecretAccessKey`, `SessionToken`) that can be exported as environment variables to make API/CLI calls as the assumed role. For example:

```bash theme={null}
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws s3 ls
```

***

## Step 4 — Switch role in the Console and verify access

* Sign in as the user `arnold2` in Account B.
* Use the Console "Switch Role" feature. Enter the Account ID of Account A (`635573991785`) and the role name `CrossAccountS3ReadRole`. Optionally set a display name and color for the session.

![A screenshot of the Amazon Web Services "Switch Role" webpage showing an Account ID field and an IAM role name/color selection dropdown (options like None, Red, Orange, Yellow, Green, Blue). The bottom right shows Cancel and Switch Role buttons.](https://mintcdn.com/kodekloud-c4ac6d9a/pbGljLCZ83hel575/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Demo-Cross-Account-Roles-and-How-to-Assume-Them/aws-switch-role-account-id-color.jpg?fit=max\&auto=format\&n=pbGljLCZ83hel575\&q=85\&s=d0a6602cce80ca333972b113405edb8c)

* After switching, the Console session runs with the role's permissions. Navigate to S3 to view the buckets in Account A and read objects as allowed by the role.

![A screenshot of the Amazon S3 web console showing the "General purpose buckets" view with a list of S3 bucket names, their AWS region and creation dates. The top bar shows actions like Copy ARN, Empty, Delete and an orange "Create bucket" button.](https://mintcdn.com/kodekloud-c4ac6d9a/pbGljLCZ83hel575/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Demo-Cross-Account-Roles-and-How-to-Assume-Them/s3-console-buckets-create-button.jpg?fit=max\&auto=format\&n=pbGljLCZ83hel575\&q=85\&s=38fe3ee94f6a277b787815739c0876a6)

Because the role has `AmazonS3ReadOnlyAccess`, you can open buckets and view objects, but write/create actions are not permitted.

***

## Step 5 — Verify permissions (attempt an action outside allowed permissions)

* While using the assumed role, try to create a bucket. Since the role is read-only, `s3:CreateBucket` is not permitted and the action will fail with an access error.

![Screenshot of the Amazon S3 "Create bucket" console. It displays a red error message: "Failed to create bucket" because the s3:CreateBucket permission is required, with the Advanced settings panel and a "Diagnose with Amazon Q" button visible.](https://mintcdn.com/kodekloud-c4ac6d9a/pbGljLCZ83hel575/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Demo-Cross-Account-Roles-and-How-to-Assume-Them/s3-create-bucket-failed-permission-error.jpg?fit=max\&auto=format\&n=pbGljLCZ83hel575\&q=85\&s=9270d071cd6216bfa30f723cd2c2508f)

* To confirm role permissions, inspect the role in the IAM console of Account A. You should see `AmazonS3ReadOnlyAccess` (or whichever policies you attached).

![A screenshot of the AWS Identity and Access Management (IAM) console on the Roles page for "CrossAccountS3ReadRole," showing its Permissions policies. The policy list includes the AmazonS3ReadOnlyAccess managed policy and controls like Simulate, Remove, and Add permissions.](https://mintcdn.com/kodekloud-c4ac6d9a/pbGljLCZ83hel575/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Demo-Cross-Account-Roles-and-How-to-Assume-Them/aws-iam-crossaccount-s3readrole-policies.jpg?fit=max\&auto=format\&n=pbGljLCZ83hel575\&q=85\&s=d6df1defb3b8a288a32c2f468169f1e1)

***

## Summary (quick reference)

| Component | Purpose |
| - | - |
| Trust policy (role in Account A) | Specifies who can assume the role — `Principal` + `sts:AssumeRole`. |
| Permission policy (role in Account A) | Defines what actions the assumed role can perform (e.g., `AmazonS3ReadOnlyAccess`). |
| Caller/user policy (user in Account B) | Allows the user to call `sts:AssumeRole` on the role ARN in Account A. |
| Console Switch Role / CLI / SDK | Methods to assume the role and obtain temporary credentials. |

Best practice: Apply least privilege. Restrict trust to specific principals and limit role permissions to only the required actions and resources (e.g., specific S3 bucket ARNs and prefixes).

## Links and references

* IAM roles and trusting third-party or cross-account principals: [https://docs.aws.amazon.com/IAM/latest/UserGuide/id\_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
* sts:AssumeRole API: [https://docs.aws.amazon.com/STS/latest/APIReference/API\_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)
* Console Switch Role documentation: [https://docs.aws.amazon.com/IAM/latest/UserGuide/id\_roles\_use\_switch-role-console.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)
* Amazon S3 documentation: [https://docs.aws.amazon.com/s3/index.html](https://docs.aws.amazon.com/s3/index.html)

> **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/d51f4260-d612-4dcb-9a91-4eeb6540c6c7/lesson/cdcb7e97-a2b4-4d1a-a858-75f7ea21ac23)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.