Using Roles to Secure Your Environment: Part 2

Mon, 15 Feb 2016

In our Part 1 post, we provided an overview of one of AWS’s most powerful and flexible security features -- roles. It can take some time and experience to fully wrap one’s mind around the varying capabilities of roles. In Part 1, we reviewed a use case for roles in which console users would be required to assume a role for access to the production environment; we have implemented this for some of our more security conscious customers for the benefits we mentioned in Part 1. In Part 2, we will review cross-account roles and some of the different use cases. Lastly, in Part 3 of this series on roles, we’ll briefly review roles for SAML providers and then do a deep dive on the benefits of EC2 roles, along with an overview on implementation and how EC2 roles have benefited the security of our customers’ environments.

Cross-Account Roles

Put simply, cross-account roles allow a user in one AWS account to assume a role in another AWS account. The two most widespread use cases behind this AWS feature are for organizations who wish to split their environment into different accounts and also for MSPs and Consulting Partners of AWS (like Trek10) to access customer accounts.

One Enterprise, Multiple AWS Accounts

Some customers choose to split their AWS infrastructure into different accounts. For example, an enterprise may have separate AWS accounts for production, staging, development, shared services, etc. It is also common to split up accounts by departments or subsidiaries. There are a few different advantages and use cases for separation of AWS accounts. It allows for very simple and visible billing (although tagging could accomplish this, this does not cover all costs and services; separating accounts makes this much simpler).

This also allows an enterprise to very easily secure access to certain types of resources -- like those in production. If all environments are in one AWS account (even in separate VPCs), there is no simple way to deny certain IAM users access to production resources. Let’s say, for example, that you want to allow developers to launch and terminate new EC2 instances in a development VPC but deny all access to the production VPC. With only one AWS account, this becomes very difficult. You can always use resource-based tagging, but this is far more complex and time-consuming (as evidenced by this post), and it simply will not work for some services and APIs. Because of this, let’s say you decide to create an entirely separate AWS account for production. Now, you can really secure this entire environment; you can require users to only access this account through a cross-account role called “prod-role.”

To illustrate cross-account roles, I sketched a drawing below:

• Each cloud represents a separate AWS account with the account name in a green box.
• The Shared Account is a separate AWS account where all IAM users reside. Each user will first log in to this AWS account before assuming a role in the environment requirement based on work requirements.
• Note that this shared AWS account need not even have any AWS infrastructure in it. It may just be an account used for billing purposes (e.g., it’s a parent account for the 3 accounts below it through which all billing flows).
• The IAM entities in the diagram are highlighted
  • Yellow highlights are actual IAM users with passwords -- each ID is associated with 1 person. John.Doe is a developer and Jane.Doe an administrator (i.e., with access to all resources) of the organization.
  • The blue highlights are roles that are assumed by all IAM users. Roles do not have passwords. The cross-account role is created and a trust relationship is configured with the Shared Account, which allows IAM users in the shared account to assume the role to switch into a different AWS account and assume the permissions given to the role through an IAM policy.

With cross-account roles, any ID in the Shared Account can be given the appropriate permissions to assume a role in one of the trusted accounts. Typically, organizations will give developers access to pre-production environments, while admins have permissions to assume a role into all environments, including production. The user assuming the role only takes on the permissions of the role, which may be full admin access to the account, or it may be read only or some other limited policy.

Using cross-account roles also makes it very simple to enforce MFA, as there is a simple checkbox (see screenshot) to require MFA in order to assume a cross account role. This is not something that is easily configurable with a checkbox within a single AWS environment without using roles. Additionally, we have customers with a separate production account that would like to know whenever their production account is accessed. This becomes very simple with cross-account roles, because rather than auditing access to any piece of production infrastructure, we can trigger a ticket based on the CloudTrail log of any user who assumes the “prod-role” to access the production environment. You can then make this role the only path into your production environment, and you will be notified whenever this path is taken through the role.

AWS MSP and Consulting Partners

Trek10, an Advanced MSP and Consulting Partner of AWS, uses cross-account roles to access all customer accounts. This has the main benefit of allowing our team to assume roles in customer environments, which means that Trek10 employees need only to manage one AWS ID, rather than an ID in each of our customer environments. In addition to requiring MFA to assume any role in a customer account from our Trek10 IAM IDs, this drastically reduces the attack surface of each of our customer accounts. Instead of creating and securing an IAM ID in each customer environment, we only need to secure our internal IAM environment to keep our access to customer accounts safe from attackers. This also has the benefit of increasing productivity; rather than logging out and back in (with an MFA code) to each customer environment throughout the day, we only need to switch roles, which does not require reauthentication.

Questions/comments? Looking for a security audit? Feel free to contact us at security@trek10.com.