As we reviewed in the Account Structure – AWS vs Azure article, AWS account provides natural access boundary for the resources within it. When users need to manage their access to multiple AWS accounts, it may not be practical to have individual identities and credentials per each account. There are a few ways to manage the identities and access more effectively. We will explore one of them, Assume Roles, in this article.
Theory
Let’s start with the smallest scope of multi-account scenario, two accounts. If a user needs to access both accounts, one way is to create two IAM users, one for each account. It doesn’t seem to be too hard to manage. If we expand the scope to be 100 accounts, remember and manage 100 credentials will be more than a headache.
Another option is to create one IAM user in one account, and grant permissions to this user to access the rest of the accounts. This way, you only need to manage one user name and password. In AWS, it’s called Assume Roles. The process of the role assumption from an IAM user is like below.
A trusted relationship between accounts is the prerequisite for role assumption. As shown in the diagram above, the authentication account hosts the IAM user credentials. The workload account hosts the workload resources. To map the accounts in a trusting vs trusted way, it’s like:
- Authentication Account (managing user credentials) = Trusted Account
- Workload Account (hosting workload/resources) = Trusting Account
The IAM user from the authentication account can then assume the role from the workload account to manage the resources, using the Security Token Service (STS) AssumeRole API operation
If it’s an application or service that needs to access resources across accounts, it’s similar to IAM user’s AssumeRole operation. The only difference is that the application or service needs permission within the local role (also called service role) to assume the remote role, as shown in the diagram below.
In summary, regardless it’s IAM user’s AssumeRole or application’s AssumeRole across to another account, what’s happening between the accounts is the same, i.e. three steps as below:
- Conduct an AssumeRole API call to the workload account
- The API call will return temporary credentials
- Use the temporary credentials to access workloads account’s resources
These steps have to repeat when the temporary credentials expires (by default 1 hour). For more details about the role assumption, see AWS AssumeRole.
Hands-on
As shown in the diagrams in the Theory section, we need to configure at least two accounts, i.e. the trusted account and trusting account. If there are more than two accounts, we will need to configure one trusted account and multiple trusting accounts. For IAM user’s role assumption and application’s role assumption, the configurations are slightly different. For details of the configurations and settings, see AWS Role Assumption Configuration.
Summary
Role Assumption enables users to access services and resources across accounts in AWS. The benefit of this method is that user admins can centrally manage their IAM user credentials in one account and access other accounts by switching roles. It significantly reduces the user credential management effort and security risks. However, for companies who have their existing user pool established, e.g. in on-prem AD or Azure AD. In this case, it’s not practical to have another user pool created in an AWS account. We will address this scenario using AWS SSO in another article.