AWS IAM Role Chaining

It may seem like a simple statement to read for the first time but you might have to go through it several times to actually get the gist of what it means (at least I had to).

Don't worry, you'll understand it via a practical example!

I came across a similar situation at work, where I had to use an IAM role in an account to assume another role in a different AWS account.

“A picture is worth a thousand words!”

Role R1 in Account 1 assuming Role R2 in Account 2

Note: The aforementioned image is incomplete and will have all the components once we reach the end.

Terminology

• U1: An IAM User in Account 1

• R1: An IAM Role in Account 1

• R2: An IAM Role in Account 2

Final Problem Statement

Let's get to the final problem statement. U1 will assume R1 to assume R2 to perform certain actions in the AWS Account 2

I've divided the article into 3 sections

1. Introduction to IAM User and IAM Role

2. How to assume a role?

3. Finally, the concept of IAM Role chaining

You can directly skip to section 3 if you already know the concept of IAM Roles and how assuming an IAM role works!

1. Introduction to IAM User and Role

What is IAM User?

• An IAM User is an entity that you create in AWS to represent the person or application that uses it to interact with AWS.

• A user can have a certain set of permissions assigned to it. The permissions define what a user can or cannot do in the AWS.

• A user in AWS consists of a name and credentials. You can access AWS in different ways depending on the user credentials but in this article, we'll be mainly focusing on the Access Keys

Long Term Credentials or Access Keys

With an IAM User, you have two different keys to make AWS requests. They don't have an expiry but you can make them inactive whenever you want.

• Access Key ID

• Secret Access Key

What is an IAM Role?

• An IAM Role like an AWS User is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.

• IAM roles are not associated with a specific user. Instead, trusted entities assume the roles.

• When a trusted entity assumes a role, a set of temporary credentials (role credentials) are provided by AWS STS (Security Token Service), which you can use to make further requests to AWS.

• When you make requests with these temporary credentials, you have the permissions associated with the role, and not your own (if you have one) because you have taken on a new identity.

  Now, you would be wondering, why go through the trouble of creating a role and then assuming it? Why not directly assign the permissions to the user itself?

Let me tell you the answer to this question!

A. Assuming roles instead of directly using the user enforces the principle of least privilege. With roles, you can:

1. Restrict the use of elevated permissions to only those times when they are needed for specific tasks.

2. Explicitly grant your users permission to assume the role. This way, not everyone is allowed to perform those tasks.

B. An IAM Role doesn't have standard long-term credentials such as a password or access keys associated with it. Temporary security credentials are valid for:

1. A specified duration. The time period after which the temporary credentials expire can be configured (max 12 hrs) offering improved security when accessing AWS Services.

2. A specific set of permissions. The temporary credentials obtained by assuming a role will have a subset of permissions that the role has. There's an option to provide policies (permissions) while assuming a role. If you don't specify these, the permissions of temporary credentials are the same as the role. But if you do specify them, then the permissions are the intersection of the role's permissions and the policies' permissions. (Read AWS documentation for more details)

C. Allow cross-account access. You can create a role in Account 2 and allow a user in Account 1 to assume the role in Account 2.

When the user in Account 1 assumes a role in Account 2, you get temporary credentials. Using those temporary credentials you can perform the actions in Account 2 that are allowed by the permissions in the Role in Account 2.

2. How to Assume a Role?

You can assume the role using the STS AssumeRole Operation.

If you're using the AWS SDK, you can use the assume role method of the STS.

• AWS SDK for Python(Boto3)

• AWS SDK for JavaScript

You can also assume the role via CLI.

aws sts assume-role --role-arn "arn:aws:iam:123456789012:role/example-role" --role-session-name example-cli-session

The access keys configured for your default profile will be used to assume the role (Read Named Profiles to know more about profiles with AWS CLI)

What are the necessary conditions to assume a role?

1. The assuming identity must have permission to assume the role

The assuming identity must have the permissions to perform the AssumeRole action on the role.

E.g, the following policy when attached to an example-user allows the assuming identity, example-user to assume example-role.

2. The role must allow the assuming identity to assume the role

An IAM role has a trust policy that defines which conditions must be met to allow the assuming identity to assume the role. Let's see an example here.

A role with the following trust policy allows any user in the AWS account with account id: (because rootin the arn) to assume this role.

Temporary security credentials

Upon assuming the role, you get temporary security credentials. It consists of 3 keys

• Access Key ID

• Secret Access Key

• Security Token

As mentioned earlier, you can use these temporary credentials to perform certain actions as permitted by the permissions of the roles for a specified duration.

3. IAM Role Chaining

In the previous sections we've talked a lot about IAM Roles, conditions that need to be met to assume a role, and how can one assume a role.

Alright! Let's cut to the chase!

Now that you've gone through the above sections, you'd have crafted an answer to the problem statement I mentioned in the first place. Although, there's one tricky and important question that remains unanswered

For assuming R1, you can use the creds of U1 to assume R1, but what creds to use for assuming R2?

Let's fill in the missing details to the incomplete image that I had shared at the beginning:

Role R1 in Account 1 assuming Role R2 in Account 2

So when we say a role assuming another role, it's actually the temporary credentials, obtained from assuming the first role, that are used to assume the second role.

NOTE: The second role can be in the same account, the example is just one of my use-cases where the second role was in a different account

Conditions for role chaining

1. U1 must have permission to assume R1.

2. R1's trust policy must allow U1 to assume R1.

3. R1 must have permission to assume R2.

4. R2's trust policy must allow R1 to assume R2.

1, 2, and 3 could be easily generated from the What are the necessary conditions to assume a role? sub-section under How to assume a role?

1. U1 must have permissions to assume R1.

2. R1's trust policy must allow U1 to assume R1.

3. R1 must have permissions to assume R2.

4. R2's trust policy must allow R1 to assume R2.

The ARN in the principal would be of the Role that'll assume the Role instead of the user.

Now, you can easily assume a role, use its temporary creds to perform certain actions, or maybe even assume another role (Role Chaining)

I hope the article pretty much covers the concepts of assuming a role and the IAM role chaining. In case of any queries, please drop a comment below. I'd be happy to help you out!