Securely Accessing Customer AWS Accounts with Cross-Account IAM Roles

As a Partner Solutions Architect, I look at a lot of AWS Partner Network (APN) Partner software and services. I like trying new things and experiencing the exciting solutions that our APN Partners are building.

Security is job zero at AWS, so when I work with our APN Partners, there’s one thing I look for above all others, and that’s to understand if the APN Partner is following best practices to protect customer data and any customer AWS account they may access.

If it seems like the APN Partner’s product will need to access a customer account, I’ll check to see how the APN Partner is getting credentials from the customer. If a partner is asking customers for AWS Identity and Access Management (IAM) access keys and secret keys, I halt my investigation and focus on helping the partner fix this approach.

It’s not that I have a problem with partners accessing customer accounts—APN Partners can add incredible functionality and value to the resources in an AWS account. For example, they can analyze AWS CloudTrail logs, or help optimize costs by monitoring a customer’s Amazon Elastic Compute Cloud (Amazon EC2) usage. The problem here is how the APN Partner is accessing the AWS account.

IAM access keys and secret keys could be used anywhere, by anyone who has them. If a customer gives these keys to an APN Partner, they need to be able to trust that the APN Partner is adhering to best practices to protect those keys. This should really resonate with APN Partners, who need to store and protect their customers’ keys, but lack control over how customers manage those keys. Using IAM access keys and secret keys for cross-account access is not ideal for anyone. Fortunately, there is a better way.

Cross-account IAM roles allow customers to securely grant access to AWS resources in their account to a third party, like an APN Partner, while retaining the ability to control and audit who is accessing their AWS account. Cross-account roles reduce the amount of sensitive information APN Partners need to store for their customers, so that they can focus on their product instead of managing keys.

In this post, I explain some of the risks of sharing IAM keys, how you can implement cross-account IAM roles, and how cross-account IAM roles mitigate risks for customers and for APN Partners, particularly those who are software as a service (SaaS) providers.

The problem(s) with sharing IAM keys

On AWS, access and secret keys are credentials that allow access to AWS APIs in an account. These can be associated with an IAM user in an account or with the root user of an account. Sharing these keys with external parties can create a lot of headache for everyone involved.

The root of the problem with sharing IAM keys is that they can be used until explicitly revoked by a customer, and that the keys can be used from any computer that has Internet access (this includes servers, laptops, mobile phones, etc.). If an APN Partner wants to use IAM access and secret keys in a customer’s product, here are some important questions that both the APN Partner and the customer should be able to confidently answer:

• Are keys being managed securely? Are they encrypted when they are transmitted and stored? Who has access to the keys? What processes protect the keys from being exfiltrated from the partner’s systems?
• Are keys being rotated frequently? If you are a customer, will the APN Partner tell you when to rotate your keys? As an APN Partner, how can you make sure all your customers frequently rotate their keys? How do you coordinate key rotation with your customers to minimize downtime?
• Can you control who has access to the customer’s AWS account? For both customers and APN Partners, how will you know who uses a key, and from where?
• Is the access policy associated with the key too permissive? For APN Partners that have a database of keys, how many of those keys provide too much access, or are root account keys?

APN Partners could build solutions that address these considerations, and customers could take on more work to ensure that their keys are being handled in a secure way. However, this involves a lot of undifferentiated heavy lifting that cross-account IAM roles can handle for both parties.

How cross-account IAM roles work

An IAM role is an AWS identity with an access policy that determines what the role can and can’t do in AWS. They are designed to be assumable by another AWS identity that is already authenticated to AWS. When an identity assumes a role, it receives temporary credentials and the same access policy as the role. You may be familiar with how roles work if you have used EC2 instance profiles, or have set up an AWS Lambda function.

A cross-account IAM role is an IAM role that includes a trust policy that allows AWS identities in another AWS account to assume the role.  Put simply, I can create a role in one AWS account that delegates specific permissions to another AWS account. Let’s take a look at the overall process as it applies to APN Partner software that needs to access a customer account:

1. A customer creates an IAM role in their account with an access policy for accessing the resources that the APN partner requires. They specify that the role can be assumed by the partner’s AWS account by providing the APN Partner’s AWS account ID in the trust policy for that role.
2. The customer gives the Amazon Resource Name (ARN) of the role to the APN partner. The ARN is the fully qualified name of the role.
3. When the APN Partner’s software needs to access the customer’s account, the software calls the AssumeRole API in the AWS Security Token Service (STS) with the ARN of the role in the customer’s account. STS returns a temporary AWS credential that allows the software to do its work.

Customers can include conditional checks on the trust policy associated with an IAM role to limit how third parties can assume the role. An example of this would be the external ID check. The external ID is a string defined in the trust policy that the partner must include when assuming a role.  External IDs are a good way to improve the security of cross-account role handling in a SaaS solution, and should be used by APN Partners who are implementing a SaaS product that uses cross-account roles.

How cross-account roles mitigate risks

Using cross-account roles addresses and mitigates a number of risks, so it’s worth taking a closer look at how cross-account roles help address the security questions we listed earlier.

• Are keys being managed securely? The Role allows the partner to get temporary credentials when they need to use them. Unlike Access and Secret Keys, these don’t need to be stored, so partner doesn’t need to be concerned with managing keys.
• Are keys being rotated frequently? Credentials generated by STS expire after an hour. Many of our software development kits (SDKs) have credential providers that handle this automatically, so neither the APN Partner nor the customer needs to manage credential rotation manually.
• Can you control who has access to the customer’s AWS account? The role in the customer’s account can be assumed only by an authenticated AWS identity in the partner’s account. The customer knows that only the APN Partner is accessing their resources, and the APN Partner can focus solely on managing and protecting the IAM roles and users in their own account.
• Is the access policy associated with the key too permissive? A role can’t have root key permissions, and since the cross-account role’s trust policy specifies the partner’s account, it is more likely that the permissions in the role’s access policy will reflect the partner’s requirements. APN Partners can encode cross-account IAM roles in AWS CloudFormation templates to make sure that customers are giving them exactly the permissions they need.

Where to go from here

In this post, I’ve explained why using IAM keys to provide AWS account access to third parties is not ideal, and talked about how APN Partners can implement cross-account IAM roles in their products. To learn more, take a look at AWS documentation on IAM roles, cross-account IAM roles, and external IDs.

Looking for implementation details? Take a look at our SDK documentation that explains how to use AWS SDKs to build this into your product. Here are links to documentation about assuming roles for the Java, Ruby, Golang, .NET, and Python SDKs. Most partners won’t need this, but if you want to see the low-level details, take a look at the STS API documentation. I also recommend that you audit your own AWS accounts using a credential report to see if you are providing cross-account access with an IAM user.

If you’re a consulting partner or an MSP, you probably find yourself needing to access your customers’ AWS accounts through the AWS Management Console. You can use cross-account IAM roles for this as well by using the switch roles feature of the AWS Management Console. This gives you access to your customers’ accounts without having to manage users, passwords, or keys.

Finally, if you’re an AWS customer and work with an APN Partner who is requiring keys, ask them how you can use cross-account roles with their products, and don’t hesitate to share this post with them.