Sometimes a business needs to structure account access on AWS in a way that ensures administrative isolation of workloads.

In this instance, it becomes necessary to create cross-account roles that establish and grant access between a trusting account and a trusted account by sharing temporary security credentials.

The trusting account contains the resources and services that need to be accessed by the users in the trusted account.

We will limit the scope of this article to only the granting of access to IAM user/group; external vendor and AWS service access will not be covered here.

A trust relationship is defined in the cross-account role inside the trusting account by specifying Account ID of Trusted Account (see Figure 2 below). Once this trust relationship has been defined, the IAM user/group in the trusted account then uses AWS STS AssumeRole API operation to acquire temporary security credentials that enable access to AWS resources in the trusting account.

Figure 1: Cross-account access structure in AWS

The architecture that is depicted in Figure 1 above consists of 2 steps viz. :

  1. Creation of the cross-account role (this activity takes place inside the trusting account)
  2. Granting IAM user/group access to the cross-account role (this activity takes place inside the trusted account) :

1. Creation of the cross-account role

1.1 Create cross-account role in Trusting Account (see Figure 2 below for detailed steps)

1.2 Edit the cross-account role’s Trust Relationship to AssumeRole by specifying Account ID of Trusted Account (also Figure 2 below)

1.3 Attach applicable policies to this cross-account role, depending on the access required by the IAM user/group in the Trusted Account (Figure 3 below) and finalize role creation (note here that “Trusted entities” account ID same as seen in Figure 2).

*NOTE: only resources and services explicitly permitted by these policies will be accessible.

Figure 2: Create cross-account role and specify Trust Relationship
Figure 3: Attach Policy to cross-account role
Figure 4: Finalize role creation

*NOTE: It is important to ensure the level of access that the users in the trusted account will be allowed once trusting account’s role has been assumed. In the example in Figure 3 and Figure 4, the policy attached to the role is “AdministratorAccess” which in a real-world setup is unlikely to ever be granted.

2. Granting IAM user/group access to the cross-account role

This action will grant temporary access to the resources which are in the trusting account. An inline policy has to be attached to the user/group, granting this access.

This access is acquired through the AWS STS AssumeRole API operation.

The steps below, show the policy creation that will grant the user/group this access:

Figure 5: Grant access to IAM group — Create inline policy
Figure 6: Inline group policy created

The AWS STS AssumeRole API operation that will pass the temporary access credentials is as below:

Figure 7: AWS STS AssumeRole API operation

The credentials that will be received following the operation depicted in Figure 7 above are valid for 1 hour as a default.

These credentials:

  • AccessKeyID
  • SecretAccessKey
  • SessionToken

can then be configured in environment variables so subsequent AWS CLI commands work using the role’s permissions.

It is always worth highlighting that — like any other implementation in cloud especially, this is to be regarded as an iterative process with a view to ALWAYS check that the access granted through this cross-account role is still the access that you want to have available.

MyCloudSeries is a training and consulting firm with expertise in Cloud Computing and DevOps. We assist organizations in their DevOps strategies, transformation, and implementation. We also provide Cloud Computing Support contact us at www.mycloudseries.com