AWS Cross Accounts Access: Part 2

In part one of this two-part blog on AWS Cross Accounts Access, we took a look at the pros and cons of using single and multiple sub-accounts as the basis for an AWS account architecture. In the process we discovered that a new feature, called 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 superadmin-like, he will obtain super admin capabilities.

Trust relationship: A trust relationship means that you trust an entity from another AWS account to takeover (assume) the role you have created for them inside your AWS account.

AssumeRole: In trust relationship, you define which AWS account can assume a role in your AWS account. Once the role is assumed, the AWS account specified in trust 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 takeover 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’ 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 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.

There are three steps involved to 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.

Flux7 is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.