Category: IAM

This walkthrough uses a role to delegate access to resources that are in different AWS accounts. You share resources in one account with users in a different account. By setting up cross-account access in this way, you don’t need to create individual IAM users in each account. In addition, users don’t have to sign out of one account and sign into another in order to access resources in different AWS accounts.

This walkthough requires 2 accounts. They do not have to be in the same organisation, but can be.

In later posts, I expand on the scenario by using the same concept for CLI access, but using the console is a good place to start before looking at that.

I will call the accounts “the trusted account” and “the trusting account”. The trusting account contains the resources that the user in the trusted account will access.

In the trusted account we will create a role which can be assumed by a user in the trusting account.

To keep it simple, I will attach an administrator access policy to the role. In real life, you would use the principal of least privilege, for example, if the user only needs access to an S3 bucket, then the policy would only allow that.

It will be useful to use a text editor as a scratch pad so you can copy and paste the two account ids, and names of roles and policies that you create.

Account ids can be seen from “My Account” in the drop down menu below the logged in username in the top right of the console.

I assume you have an IAM user with full admin rights set up in each account.

In the trusting account:

Navigate to IAM,Roles, Create Role.

For “Select type of trusted entity”, select “Another AWS Account”

Supply the account ID of the trusted account,  and click Next.

For “Attach permission policies” select “AdministratorAccess”.

I named the role “CrossAccountRole”

The role now has two policies: the “AdministratorAccess” policy, and a Trust policy. To see the trust policy, select the role, click on the “Trust Relationships” tab, and click “Edit trust relationships”.  It will be similar to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<trusted account id>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

This policy allows a user in the trusted account to potentially assume the role. However, they still need permissions in order to assume the role. Any user with Administrator Access in the trusted account has such permissions. They would also be able to give other users permissions to assume the role. This is called delegation, which we will see how to do later.

In the trusted account:

In the top right of the console, below the logged in user name, select “Switch Role” from the drop down menu.

Supply the account id of the trusting account, the name of the role “CrossAccountRole”, choose a display name, and click “Switch Role”. You are now logged in to the trusting account with Administrator rights. From the same drop down menu in the top right, you can choose “Back to <username>” to switch back.

And that concludes the first part of the walkthrough.

In real life, you would use the principal of least privilege. The cross account role in the trusting account would allow only the required permissions, and the user in the trusted account does not need to be an admin in the trusted account.

To see how an ordinary, non admin user could be given permissions to assume the role:

In the trusted account:

Create a policy. For service, choose STS. For “Access Level”, choose Write, then tick AssumeRole. For resource, choose Specific.  You are given a friendly way to generate the ARN by supplying the trusted account id and the name of the role in the trusted account.

Click Review Policy and supply a name for the policy. I called it “AssumeCrossAccountRole”

The policy will look something like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<trusting account id>:role/CrossAccountRole"
        }
    ]
}

Create a user. I named the user “TrustedUser”. Allow Console Access, and click Next. Choose “Attach existing policies directly” and select the policy “AssumeCrossAccountRole” just created.

To test it, login to the trusted account as “TrustedUser”. We gave minimal permissions for the  “TrustedUser”, just enough to assume the role, so you will see many permissions warnings. However, you can choose “Switch Role”, supply the details, and gain access to the trusted account as before.

IAM is a free service, but if you want to clean up:

In the trusted account:

Delete the user “TrustedUer”

Delete the policy “AssumeCrossAcccountRole”

In the trusting account:

Delete the Role “CrossAccountRole