In the Advanced Architecting on AWS course there is a slide on switching roles.
The process is as follows:
In this post, I will walk through the set up for CLI. In a previous post, went through the steps to configure the same using the console.
I assume you are familiar with the CLI, how to configure keys for CLI use, and the concept of roles.
The pre-requisites are as follows:
Create a second AWS account. I will refer to the two accounts as the Trusted Account and Trusting Account. The two accounts can be part of the same organisation, or not.
Install the AWS CLI on your local machine (or an EC2 instance if you don’t want to mess with your local machine. The AMZ Linux2 AMI has the AWS CLI already installed)
Create a user in the trusted account. Select the access-type Programmatic Access. I named the user “Admin” and attached the AWS managed policy “AdministratorAccess”. Save the credentials.
Use “aws configure” to configure the access-key and secret-access-key on the local machine.
Configure a role in the trusting account as follows:
In the IAM console, create a Role, and for the type of trusted entity, select “Another AWS account” and supply the account ID of the trusted account. I named the role “CrossAccountAdminRole” and attached the AWS managed “AdministratorAccess” policy.
The role ends up with a trust policy similar to:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<trusting account id>:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
Perhaps not obvious, but this doesn’t mean that only the root user of the trusted account can assume the role. It means that any user in the trusted account with appropriate permissions can assume this role. Appropriate permissions means sts:assume role permission for this particular named role. In my case, I will be using a user with Administrator rights in the trusted account, so it will have permissions. In real life, the administrator can attach a policy to the trusted user which allows the user to assume the role similar to this:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::<trusted account id>:role/CrossAccountAdminRole" } }
To summarise the above, cross account roles requires two things:
- The trusting account administrator creates a Role, and give the trusting account permissions to assume it.
- The trusted account administrator gives users in the trusted account permission to assume the role.
Finally we get to the point of the post:
There are just two lines to configure as follows:
aws configure set profile.<profilename>.role_arn arn:aws:iam::<trusting account id>:role/CrossAccountAdminRole aws configure set profile.<profilename>.source_profile default
Where <profilename> is anything you want
This configures the profile to allow the default profile (which for me is Admin in the trusted account) to assume the role CrossAccountAdminRole in the trusting account.
To test it you could create a resource in the trusting account, for example an S3 bucket and then type:
Aws s3 ls –profile <profilename>
The .aws/config file looks similar to this:
[default] region = eu-west-1 [profile testprofile] role_arn = arn:aws:iam::123456789012:role/CrossAccountAdminRole source_profile = default
By appending –profile <profilename> to the command, the CLI will use the profile, which is configured for an IAM role. The CLI will automatically make an STS:AssumeRole call and cache the returned temporary credentials. Subsequent calls made using the same profile will use the cached temporary credentials until they expire. When the credentials expire, the CLI will automatically repeat the process to acquire new credentials.
With this method, you keep your trusting account secure by using temporary credentials, and you manage IAM users by keeping your users in one account, the trusting account.