Ryfujk

There are a number of AWS accounts which I don't control. I've had the account owners deploy an IAM Role, TrustingSecurityAuditor, into their accounts which grants the right to assume the TrustingSecurityAuditor role to a different IAM role in my AWS account, TrustedSecurityAuditor. (Docs on delegating access)

This works great and allows me and my security team to provide security auditing services to these other account holders in the company. To do this we spin up an ec2 instance with the TrustedSecurityAuditor IAM role and our code requests temporary credentials from each of the accounts using STS by doing an AssumeRole to each account's TrustingSecurityAuditor role.

Now I want to create an additional service running on a different ec2 instance in my account which can not only assume the role of these "Trusting" accounts, but also do other things in my account, like access my account's DynamoDB to store information.

If I apply the TrustedSecurityAuditor role to the instance I don't have the local permissions I need (like DynamoDB access).

I can't apply multiple IAM roles to an instance (unless I'm mistaken).

When I attempt to create a new role, MyNewService, with DynamoDB access that can AssumeRole to the TrustedSecurityAuditor role in hopes of then using those STS credentials to do a second AssumeRole to the TrustingSecurityAuditor role in the foreign account I encounter this problem :

I'm able to AssumeRole from the MyNewService role to the TrustedSecurityAuditor role, but when I do the second AssumeRole to the TrustingSecurityAuditor role AWS returns the error

User: arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor/MyNewService is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/TrustingSecurityAuditor

The reason for this is that the "user" attempting the AssumeRole is

arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor/MyNewService

not

arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor

What this implies is that you can not chain your AssumeRoles because the ARN that a call originates from, when it comes from an assumed role is not the assumed role alone, but the assumed role with the assumer's rolename stuck on the end.

One solution which I'm reluctant to use is that I could just add the permissions I need, for example the ability to use DynamoDB to the TrustedSecurityAuditor role. The reason I'm reluctant is that I only need this permission on the MyNewService instance, not on my original instance which only does security auditing and has no need to access DynamoDB.

Any suggestions how to accomplish what I'm looking for?

Scenario:

• AccountA - your account


• AccountB - customer account


• RoleA - Your account role to access DynamoDB, call STS, etc.


• RoleB - TrustedSecurityAuditor role in AccountB

You will need to manage two sets of credentials. Credentials A which are created from the IAM role assigned to the EC2 instance. Use these credentials to access your resources such as DynamoDB. Credentials B which are created via STS from RoleB. Use these credentials to access your customers resources.

You will then need to independently use the credentials based upon what you want to do. For example if you are using Python you would create two boto3 clients with different credentials.