AWS Cross Accounts Access: Part 2

AWS Cross-Account Access offers an ideal approach, effectively navigating away from as many negatives of each approach as possible while maintaining as many of the benefits as possible. Given the strength of AWS’ Cross Accounts Access approach, let’s take a deeper look at how you might go about architecting for the new feature and the benefits of doing so.

Using Cross-Account Access

Granting access to resources in one AWS account to a trusted principal in a different AWS account is often referred to as cross-account access. Roles are the primary way to grant cross-account access. However, with some of the web services offered by AWS you can attach a policy directly to a resource (instead of using a role as a proxy). These are called resource-based policies, and you can use them to grant principals in another AWS account access to the resource. To make it more clear, we have provided below some of the key concepts associated with the cross-account access feature:

• Role: anyone can play a role that has been assigned to them, thus they will obtain abilities of that role. If the role is super admin-like, he will obtain super admin capabilities.
  
  
• Trust relationship: A trust relationship means that you trust an entity from another AWS account to take over (assume) the role you have created for them inside your AWS account.
  
  
• AssumeRole: Intrust relationship, you define which AWS account can assume a role in your AWS account. Once the role is assumed, the AWS account specified intrust relationship obtains abilities (permissions) that are specified for that role.
  
  
• Permissions: Each AWS entity can have a specified set of abilities = permissions. When we trust somebody to take over a role inside our account, we definitely want to make sure we are giving this role only to desired abilities. Permissions are specified inside policies.
  
  
• Policies: In AWS’s world, policies control what a specific individual can do with specific resources. Policy documents are created and attached to users or roles. When users or roles make API calls to AWS services, they are evaluated against policy documents. For example, ‘Am I authorized to do this operation?’

A basic analogy of the difference between IAM users and AssumeRole is handing someone an access badge (which could be used by anyone) vs handing someone an access badge that requires that person’s fingerprints to successfully use it. Further:

• Using an IAM user to control 3rd party access involves handing over a key/secretKey, analogous to the simple “access badge”.
  
  
• Using AssumeRole to control 3rd party access uses the same information plus a security token. To assume a role, your AWS account must be trusted by the role. The trust relationship is defined in the role’s trust policy when the role is created. This is the “access badge with fingerprint validation”.

Apart from the security benefits, it is worth mentioning that with Cross-Account Access:

• You use one set of credentials, alleviating password fatigue. It allows you to gain access to other accounts on a temporary basis without having to sign-in.
  
  
• You do not have to share anymore long term credentials.
  
  
• You can revoke access to the role anytime you want.
  
  
• 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 in 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.
  
  
• There are three steps involved in protecting cross-account access using Multi-Factor Authentication (MFA). First, establish trust between accounts, then configure MFA devices for users, and finally perform privileged actions. It is very simple to enforce MFA once it has been configured.
  
  
• We can inform clients when one of their environments 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 role to access the production environment. We can then make this role the only path into the production environment, and the client will be notified whenever this path is taken through the role.
  
  
• Additionally, we can assume roles in customer environments, which means that we need only to manage one AWS ID, rather than an ID in each of our customer environments. 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 re-authentication.

In examining AWS Account Architecture closely it is easy to see that it is indeed critical to building a foundation that will grow with and support the needs of the business. For most organizations, we recommend a hybrid, multiple account strategy using Cross-Account Access. The new AWS feature maintains many of the benefits of other account architecture choices and achieves critical goals such as security while avoiding the overhead and fatigue associated with managing typical child accounts.

To learn more about the benefits of AWS Cross-Account Access, or to schedule an assessment, please contact us today.

Did you find this useful?

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.