How to chain AWS IAM AssumeRole API calls

amazon ec2amazon-iamamazon-web-services

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?

Best Answer

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.

Update

Mike Pope has published a nice article about Granting Permission to Launch EC2 Instances with IAM Roles (PassRole Permission) on the AWS Security Blog, which explains the subject matter from an AWS point of view.

Initial Answer

Skaperen's answer is partially correct (+1), but slightly imprecise/misleading as follows (the explanation seems a bit too complex for a comment, hence this separate answer):

To launch an EC2 instance with an IAM role requires administrative access to the IAM facility.

This is correct as such and points towards the underlying problem, but the required administrative permissions are rather limited, so the following conclusion ...

Because IAM roles grant permissions, there is clearly a security issue to be addressed. You would not want IAM roles being a means to allow permission escalation.

... is a bit misleading, insofar the potential security issue can be properly addressed. The subject matter is addressed in Granting Applications that Run on Amazon EC2 Instances Access to AWS Resources:

You can use IAM roles to manage credentials for applications that run on Amazon EC2 instances. When you use roles, you don't have to distribute AWS credentials to Amazon EC2 instances. Instead, you can create a role with the permissions that applications will need when they run on Amazon EC2 and make calls to other AWS resources. When developers launch an Amazon EC2 instance, they can specify the role you created to associate with the instance. Applications that run on the instance can then use the role credentials to sign requests.

Now, within the use case at hand the mentioned developers [that] launch an Amazon EC2 instance are in fact EC2 instances themselves, which appears to yield the catch 22 security issue Skaperen outlined. That's not really the case though as illustrated by the sample policy in section Permissions Required for Using Roles with Amazon EC2 :

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect":"Allow",
      "Action":"iam:PassRole",
      "Resource":"*"
    },
    {
      "Effect":"Allow",
      "Action":"iam:ListInstanceProfiles",
      "Resource":"*"
    },
    {
      "Effect":"Allow",
      "Action":"ec2:*",
      "Resource":"*"
    }]
}

So iam:PassRole is in fact the only IAM permission required, and while technically of administrative nature, this isn't that far reaching - of course, the sample policy above would still allow to escalate permissions by means of listing and in turn passing any available role, but this can be prevented by specifying only those roles that are desired/safe to pass for the use case at hand - this is outlined in section Restricting Which Roles Can Be Passed to Amazon EC2 Instances (Using PassRole):

You can use the PassRole permission to prevent users from passing a role to Amazon EC2 that has more permissions than the user has already been granted, and then running applications under the elevated privileges for that role. In the role policy, allow the PassRole action and specify a resource (such as arn:aws:iam::111122223333:role/ec2Roles/*) to indicate that only a specific role or set of roles can be passed to an Amazon EC2 instance.

The respective sample policy illustrates exactly matches the use case at hand, i.e. grants permission to launch an instance with a role by using the Amazon EC2 API:

{
  "Version": "2012-10-17",
  "Statement": [{
      "Effect":"Allow",
      "Action":"ec2:RunInstances",
      "Resource":"*"
    },
    {
      "Effect":"Allow",
      "Action":"iam:PassRole",
      "Resource":"arn:aws:iam::123456789012:role/Get-pics"
    }]
}

Best Answer

Related Solutions

Which permissions/policies for IAM role to be used with CloudWatch monitoring script

How to specify an IAM role for an Amazon EC2 instance being launched via the AWS CLI

Update

Initial Answer

Related Topic