How to Improve Project Security by Automating and Managing AWS Multi-Account Access

By Robert Patt-Corner, Principal Consultant and Cloud Architect at EGlobalTech
By Chris Weilemann, Solutions Architect at AWS

Many of our enterprise customers at EGlobalTech improve project security by segregating individual projects, or project environments like DEV or PROD, in separate Amazon Web Services (AWS) accounts.

Mapping each project or project environment to a unique account provides a clear and easy way to maintain security boundaries and built-in cost accounting.

At EGlobalTech, we use a project-per-account model for accounts we manage, and strongly encourage it for our customers who self-manage their AWS facilities.

In this post, I will focus on techniques we use to enable users to seamlessly move between their AWS accounts and roles.

I will also discuss ways to enable AWS administrators to securely and easily manage the infrastructure that makes a secure flow between roles safe and possible.

EGlobalTech is an AWS Advanced Consulting Partner with the AWS Government Competency. We provide customers with capabilities for migration, re-engineering, DevOps security, data science, machine learning, and automation through innovation.

Why Use Project-Based Accounts

Until recently, many AWS customers managed multiple projects together in an AWS account, using either manual or script-based techniques.

This enabled customers to maintain project security boundaries and track per project costs by means of tags and identity and access management (IAM) tag enforcement policies.

Even with these approaches, we typically see a degree of account-based separation, mostly segregating production-level resources in one account, and development or test resources in another, as illustrated below.

Figure 1 – Typical legacy project and environment separation.

With the advent of AWS Organizations, customers can create and manage multiple accounts more easily, with a central view across accounts and new security capabilities to set security policies at the account level.

Assigning each project or environment to an account provides a clear and easy framework to maintain security boundary and built-in cost accounting, as illustrated below.

Figure 2 – Assigning projects and environments to separate accounts.

Project-Based Account Challenges

Project-based accounts deliver immediate security and accounting benefits, but project workers need to frequently jump between a larger set of accounts to carry out their daily activities.

When EGlobalTech first provisioned project environments on a per-account basis, we found ourselves moving between accounts a dozen or more times a day. The repeating log in/out cycle became tedious, and the demands of behind-the-scenes administration became difficult to manage.

Enforcing multifactor authentication (MFA), which is an important security best practice, compounded the issue as each identity in each account required a separate MFA device and authorization.

Federating our accounts with a SAML identity provider such as Active Directory provided some relief, but still required many steps to move between accounts. SAML federation also added the overhead of configuring the Active Directory Federation Services (ADFS) claim rules, which can be complex, opaque, and difficult to administer.

Role Assumption – A Partial Solution

AWS provides a framework to solve the problems associated with managing a large number of accounts many times per day via the role assumption mechanism and AWS Identity and Access Management (IAM).

In role assumption, an IAM user (called a principal) asserts permission to assume a role in a trusting account. The role in the trusting account must also be configured by AWS account administrators to trust any aspiring asserting principal. Both the assertion and trust sides of the relationship must be satisfied for role assumption to work.

On the left side of Figure 3, you see an assertion policy attached to a principal in the trusted account. The policy grants the trusted principal the ability to assume any of six roles in various trusting accounts. The assertion policy is necessary but not sufficient for a principal to assume a role. The role in the trusting account must also designate the asserting principal as a trusted entity.

On the right side of Figure 3, you see one of the roles the principal on the left can assume in one trusting account. This role in the trusting account shows a trust policy that designates two trusted principals, identified by their AWS Resource Name (ARN). For assumption to work, one of the ARNs in the trust relationship must be the ARN of the principal in the trusted account on the left.

Figure 3 – Basic components of role assumption.

Once the principals and roles are configured, a principal can authenticate to prove who they are, and then assume a role in a trusting project account, carry out their work, and subsequently assume another role in another project account and work there.

The process is very convenient on the user side—a principal can assume a role by entering a URL shown on the role itself (as shown in Figure 4 below). Once the role has been assumed, the principal can go back to the account they authenticated with, or assume another role, all with menus or the AWS Command Line Interface (CLI).

Figure 4 – Built-in URL to assume AWS roles from AWS console.

Issues with Role Assumption

While role assumption is easy and efficient in theory, we found significant practical issues that we address in this post:

• Managers must precisely maintain the principal policies and role trust relationships in parallel. This task is nearly impossible to accurately carry out by hand, and difficulty increases exponentially with the number of principals and accounts involved. The manual solution does not scale.
• There’s no easy way to view and understand the network of relationships between principals and the roles they can assume.
• Auditing is available via AWS Config and AWS CloudTrail, but is difficult to configure and difficult to view against the “noise” of the other audited actions in the accounts involved.
• There are limitations on the user side; chief among them is that a browser only remembers the last few roles that have been assumed because the history is stored in a cookie with a limited size.

The keys to a satisfactory role-assumption solution are:

• Reliable scripting to precisely and securely manage the role-to-principal relationships.
• Dashboard interface to visualize and manage the principal to role and account permissions.
• Access-oriented auditing to give a clear view of how principals have been allowed to access roles in different accounts at any point in time.
• Improved switching mechanism for end users that enables persistent multiple account and role switch configurations that can be synchronized with actual permission capabilities.

jmpr Solutions – User Perspective

At EGlobalTech, our internal practice implemented a solution called “jmpr” around a project-based account model that is illustrated in Figure 5 below.

Each AWS user in an AWS partition has a single principal for authentication purposes in a single shared account called a “jump” account. Users authenticate once to a principal in the jump account, using MFA as a best practice.

A partition is an independent set of AWS regions, such as AWS Commercial, AWS GovCloud (US), or AWS China. AWS keeps partitions separate, so a user working with multiple partitions needs a principal in each partition they access. The jmpr model works through a jump account in each partition to provide an AWS user access in multiple partitions.

For security reasons, we recommend jump accounts contain only IAM resources needed to access other accounts and roles. Principals in the jump account should have no permissions other than the ability to assume authorized roles in other accounts.

Once a user establishes their identity in a jump account, they can seamlessly and securely move between all of the accounts and roles they are configured to access. They can do this using either native AWS role switching, or the open-source AWS Extend Switch Roles browser plugin. This offers the convenience of easy setup and a longer list of roles to jump between, but is not a necessary component of a jmpr solution.

Administrator’s Perspective

Managing Permissions

Providing a seamless user experience is the simplest part of the multi-account challenge. The major difficulty lies in scripting, presenting, and auditing the underlying complex relationships that enable secure account jumping.

Our current approach, featured in this post, delivers scripting, presentation and auditing via a web application.

Figure 5 – AWS Extend Switch Roles enhanced console menu..

1. The highlighted Manage Permissions tab illustrates the core permissions management function. The Manage Configuration tab handles configuration elements like accounts, roles, principals, persons, and accounts. The Commit Summary tab shows the audit trail of commits to date.
2. Persons and principals are assigned their roles in each target account.
3. The Apply button stages permission changes to the right hand Pre-Commit Summary portion of the screen for review.
4. On the right, staged changes can be saved, reviewed, discarded or committed. Committing a series of changes implements the desired role relationships.

Permissions management in this situation becomes intuitive. When a manager receives a request to adjust a person’s permissions, they select the person, select the account the person needs adjusted, and adds or removes roles as required. They can then stage the changes to the right-hand part of the screen.

We stage permission changes instead of committing them directly because we find that permission changes tend to come in groups:

• A single AWS user/person often needs several roles adjusted in multiple accounts at the same time. For example, they may need a read-only role in a new project production account and a read-write role in the corresponding project development account
• Permission changes typically come in batches; for instance, a request to add 10 people to a new project’s accounts.

Staging also allows for deferred commit; managers can save staged commits for later review or approval.

Committing Changes

A set of changes can be committed once they are staged and reviewed. Each commit can include a brief comment describing the purpose of the commit, and documents the changes that are part of the commit.

Figure 6 – Committing staged permissions changes.

The manager sees a notification in the right-hand notifications area when the commit is complete.

Figure 7 – Permissions change completion.

Reviewing and Auditing Changes

Managers view the commit results, along with an audit history of all the changes carried out by the tooling from the Commit Summary tab or the link in the notifications area.

Figure 8 – Viewing and auditing permissions changes.

1. The Commit Summary tab gives managers access to an audit of commits for a configuration.
2. Selecting the top commit shows the most recent comment in the right-hand pane.
3. The rest of the audit history is available for view as needed.
4. Tabs in the right-hand pane show:
   • Actions: what actions were carried out in the selected commit.
   • Messages: all log messages created during the commit, including errors.
   • User configurations that managers can transmit to users to configure their browsers to jump between accounts and roles.
   • Requested changes that capture the staged changes for this commit.

Communicating and Synchronizing with the Users

Users need efficient ways to understand their capabilities have changed, and how to access their revised roles. The User Configuration tab provides the AWS Extend Switch Roles browser plug-in configuration on a per-person basis.

Figure 9 – Generated user configurations for role assumption.

The user replaces the entire browser plugin configuration after a change, so it’s a manual process on their part that we expect to further automate over time.

Summary

Customers can improve security, accounting, and management capabilities by organizing project environments in separate AWS accounts and overcoming the consequent obstacles through automated tooling such as jmpr.

Benefits of account-based organization and jmpr access management include:

• Clear, effective, and maintainable security boundary around project environments.
• Smooth and secure user experience moving between projects.
• Support for easier, accurate, and effective project cost accounting.
• Clear view of the current network of people and their permissions.
• Accessible audit trail of past configurations and permission changes.

Authentication is provided by an Amazon Cognito framework described in Otto Kruse’s excellent blog post.

Role switching can optionally use the AWS Extend Switch roles browser plugin by Toshimitsu Takahashi.

To learn more, investigate the specifics of AWS Organizations, and read about the mechanics of Role Assumption. Then, dive deep with EGlobalTech’s automation solutions for identity and permissions management.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

EGlobalTech – AWS Partner Spotlight

EGlobalTech is an AWS Advanced Consulting Partner that provides customers with capabilities for migration, re-engineering, DevOps security, data science, machine learning, and automation through innovation.

Contact EGlobalTech | Partner Overview

*Already worked with EGlobalTech? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.