Enable a New Feature in the AWS Management Console: Cross-Account Access

Today, we made it possible for you to enable a user to switch roles directly in the AWS Management Console to access resources across multiple AWS accounts—while using only one set of credentials. Previously, as Anders discussed in his blog post, Delegating API Access to AWS Services Using IAM Roles, you could delegate access to resources only through the API. No longer! Now, any IAM or federated user can take advantage of a new console feature and simply switch to a role in an AWS account to access the resources permitted by the policies attached to that role. This allows you to grant your users access to resources in your company’s accounts without having to maintain multiple user entities and your users having to remember multiple passwords. If you already have configured roles for cross-account API access, your users can immediately take advantage of this new functionality.

In AWS, a role is a security principal that can be assigned policies that grant permissions to perform actions on AWS resources. Unlike with a user account, though, you don’t sign in to a role. Instead, you are already signed in as a user, and then you switch to the role, temporarily giving up your original user permissions and assuming the permissions of the role. When you are done using the role, you revert to your user’s permissions again. 

As documented in the IAM User Guide, an administrator creates a role in an account with resources to be managed, and then specifies the AWS account IDs that are trusted to use the role. The administrators of the trusted accounts then grant permissions to specific users who can switch to the role.

Delegating access through roles this way can help you improve your security posture by simplifying the management of credentials. Instead of having to provide your users with sign-in credentials for every account that they need to access, users only need one set of sign-in credentials. Your potential attack surface area is reduced by having fewer user credentials that you have to create and manage, and your users will be happy because they don’t have to remember multiple passwords.

This new feature can even be used to help improve security within a single account. Most of us are aware of the need to keep to the security principle of “least access,” but when you create a typical user, you give that user permissions to access all of the resources needed to do the job—even the most sensitive and rarely accessed resources. Ideally, a user shouldn’t have any access to the sensitive and critical resources until actually needed. The ability to delegate permissions to a role and allow a user to switch to the role solves this dilemma. Grant the user only those permissions that allow access to the normal day-to-day managed resources and not to the sensitive resources. Instead, grant to a role the permissions to access sensitive resources. The user can switch to the role when needing to use those resources and then switch right back to their user account. This feature helps reduce the attack surface area.

Walkthrough

Let’s set up an example scenario to walk through this feature. We have a user, David, in one AWS account who needs occasional access to a DynamoDB table owned by another account that supports a mission-critical application. David’s regular user permissions do not allow this access. Start by creating a role in the account that owns the DynamoDB table. In the IAM console for this account, click Roles, and then click Create New Role. For our scenario, let’s call it AccessToProdDynamoDB.

On the next page, expand the Role for Cross-Account Access section, and then click Select next to Provide access between AWS accounts you own.

Next, type the AWS account ID that contains the users (David, in this case) that you want to grant access to. Even if the user is in the same account, you must type the account ID. At this point, you can choose to require multi-factor authentication (MFA) to access the role. Note that a user cannot supply the MFA one-time password at the time of role switching; it must be provided when signing in to AWS as the original user. If MFA is not used at sign-in time, any attempt to switch to a role that requires MFA fails.

Next, set the permissions granted to users after they switch to this role. Because we need to grant permissions to manage our DynamoDB tables, we select the Amazon DynamoDB Full Access template.

On the next page, the policy template shows a line that reads “Resource”: “*”, which gives access to every DynamoDB table accessible by the account. You should replace this line with a resource line that enables access only to the tables that David needs to do his job. For example, the following line grants access to only the single table called GameScores (of course, you must also replace the 12-digit account ID, which contains the DynamoDB table):

“Resource”: [“arn:aws:dynamodb:us-west-2:123456789012:dynamodb:table/GameScores”]

Click Next Step. On the Review page, make note of the new role’s ARN. You will need it in the next step.

Also, be sure to make note of the predefined URL to give to the user. Instead of having to type the account ID number (or alias) and role name manually, clicking the link takes the user directly to the Switch Role page with those details already filled in. That’s all that needs to be done in the account with the resources.

Now, configure the users that need access to the DynamoDB table in the other account. In the account that contains the users, open the IAM console, click Groups, and then select (or create) the group of users that you want to enable to use the role. You can do this by editing an existing policy for the group, or you can create a new one. For this example, we create a new policy with these permissions and add David to the group. The “Resource” line is where you need the ARN from the previous step.

{
“Version”: “2012-10-17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “sts:AssumeRole”,
“Resource”: “arn:aws:iam::ProductionAccountID:role/AccessToProdDynamoDB”
}
}

Up to this point, these steps are identical to the process for delegating access to a resource for cross-account API access. But here’s where the new console feature comes into play. First, David signs in to the AWS Management Console. Because he’s a member of the group to which you granted permissions, he’s able to use the role. Ideally, David’s administrator emailed him the link provided by the Create Role wizard or displayed in the Summary section of the role detail page. If David clicks that link, his browser opens directly on the Switch Role page with the Account ID and Role Name fields already filled in. Note that the account ID can be the 12-digit number or the alias, if the account has one.

David can also get to the Switch Role page at any time manually. He can see which user he is signed in as in the navigation bar in the upper-right corner of the console. This is the Identity menu. Click it, and then click Switch Role.

The first time David tries to switch roles, either by selecting Switch Role in the Identity menu or via the predefined URL, he sees a first-run webpage with additional links to explore for more information. After he clicks Switch Role on the first-run webpage, the Switch Role page appears. If David used the predefined link, the account ID (or alias) and the role name are automatically entered in the appropriate fields. If David does not use the predefined link, he must get the account ID (or alias) and role name from the administrator and manually type them in the appropriate fields.

However David got here, he can also specify a Display Name and a Color that display in the navigation bar when the new role is active. These display choices serve as visual reminders that David is currently operating with a different set of permissions than the user he signed in as. A default Display Name is suggested, based on the account ID (or alias) and the role name, but David can type any text he wants to see. In our example, David selects PRODUCTION to be displayed in red.

When David clicks Switch Role, he immediately begins operating with the permissions in the other account granted by the AccessToProdDynamoDB role. The Identity menu shows David’s chosen display name (PRODUCTION) highlighted by his chosen color (pink).

When David has completed the task for which he needed the role, he can exit back to the David user he originally signed in as by clicking the display name (the Identity menu) in the navigation bar and clicking Back to David.

The AWS Management Console remembers under Role History the last five roles that were switched to. The next time David needs to perform tasks on the DynamoDB table, he can simply click the Identity menu and see that the PRODUCTION entry is still there. He just needs to click the display name to switch to that role again.

Conclusion

Taking advantage of this new feature can help you reduce the number of users that you have to create and maintain across your accounts and reduce the number of passwords that your users have to remember. This feature can also help you limit user access to sensitive resources so that users access sensitive resources only when necessary.

To learn more about switching roles by using the AWS Management Console, visit the Roles section of the IAM User Guide. If you have questions or suggestions, please post them on the IAM forum.

Thanks for reading!

– Dave

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.