AWS Role Assumption Configuration

As we reviewed in the AWS Cross Account Access – Assume Role article, IAM users and applications can access resources across accounts using role assumption. We’ll go through the detailed configuration steps for both scenarios in this article.

IAM User Cross-account Access Configuration

Before starting the configuration, first consider which AWS account should be used to host the IAM user credentials. If there are one production account and one non-production account, it’s recommended to host the IAM user in the non-production account to avoid having the production resources and critical credentials in the same place. Or another scenario is to have a dedicated authentication account to host all IAM users. We’ll use the second scenario to demonstrate how to set up cross-account access.

At a high-level view, we will go through the following key configurations:

In the Authentication Account

To get started with the authentication account, make sure to have the user admin access (IAM full access privilege) ready, and then follow the steps below.

1. Log in to the authentication account as the user admin

2. Navigate to the IAM page, click Policies on the left panel, and then click the Create policy button.

3. In the Create policy window, click the JSON tab, paste the following policy code, and then click the Next:Tags button.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "*"
        }
    ]
}

4. Add necessary tags, and then click the Next: Review button.

5. Add policy name (e.g. AssumeRolePolicy) and description, and then click the Create policy button.

6. Navigate back to the IAM page, click Users on the left panel, and then click the Add user button.

7. On the Set user details page, enter the user name (e.g. richard), select the AWS Management Console access option, choose your desired console password option, and then click the Next: Permissions button.

8. On the Set permissions page, select Attach existing policies directly, search for the policy we just created (e.g. AssumeRolePolicy), select the policy in the search result, and then click the Next:Tags button.

9. Add necessary tags, and then click the Next: Review button.

10. Make sure all details are entered as expected, and then click the Create user button.

Having the IAM user created in the authentication account, let’s move on to the workload account.

In the Workload Account

Before starting with the Assumed Role creation in the workload account, make sure to have the following items ready :

  • User admin access (IAM full access privilege) to the workload account
  • Authentication account id noted down
    e.g. 111111111111

Once you have the required information ready, follow the steps below:

1. Log in to the workload account as the user admin

2. Navigate to the IAM page, click Roles on the left panel, and then click the Create Role button.

3. On the Select type of trusted entity page, select Another AWS account, enter the authentication account id (e.g. 111111111111) in the Account ID field, and then click the Next:Permissions button.
MFA and External ID are optional. More information about External ID can be found at AWS Security Blog.

4. On the Attach permissions policies page, based on the workload resources that the IAM user needs to access, select or create required policy to attach to this role. For example, if you want to grant the IAM user access to only view the list of S3 buckets, the sample policy is like below.

{
  "Version": "2012-10-17",
  "Statement": [
  {
  "Effect": "Allow",
  "Action": [
  "s3:ListBucket"
   ],
  "Resource": "arn:aws:s3:::workload_acount_s3bucket_name/*"
  }
 ]
}

Once you are finished attaching the policy, click the Next:Tags button.

5. Add necessary tags, and then click the Next: Review button.

6. Add role name (e.g. AssumedRole) and description, and then click the Create Role button.

Testing

Once the role is created in the workload account, the trust relationship is established and ready for testing. To test the cross account access, follow the steps below:

1. Log in to the authentication account using the new IAM user’s credentials

2. Click the drop down icon next to the user name and account id at the top right corner of the console, e.g. richard@111111111111

3. Select Switch Roles from the the drop-down menu

4. On the Switch Role page, enter the workload account id, the role name and preferred display name, and then click the Switch Role button.

If everything have been configured as expected, you’ll be able to switch to the workload account using the assumed role. You should be able to see the display name you entered in step 4 above. If no custom display name is entered in that step, the default name will be displayed as something like <assumed role name>@<workload account id>, e.g. AssumedRole@222222222222

With the authentication tested, the next thing is to verify the authorisation as whether you can access the workload resources based on what you’ve defined in the assumed role’s permission policy. With the authorisation setting confirmed, the IAM user cross-account configuration is completed and ready for use.

Application Cross-account Access Configuration

AWS services (e.g. Lambda) or applications hosted in AWS (e.g. applications that run on an EC2 instance) can also assume roles to access resources in another AWS account. We will demonstrate how to set up cross-account access for applications and services via the steps below.

At a high-level view, we will go through the following key configurations:

In the Authentication Account

Before we start, make sure to have following items ready:

  • User admin access (IAM full access privilege) to the authentication account
  • Workload account id noted down
    e.g. 222222222222
  • Both assuming role name and assumed role name decided and written down
    e.g. AssumingRole, AssumedRole

Once the prerequisites are met, follow the steps below to create the assuming role

1. Log in to the authentication account as the user admin

2. Navigate to the IAM page, click Roles on the left panel, and then click the Create Role button.

3. On the Select type of trusted entity page, select the AWS Service option, and

  • If the application (that will assume the role) is hosted in an EC2 instance, choose EC2;
  • If it’s an AWS service (that will assume the role), choosed the service name from the service list, e.g. Lambda,
    and then click the Next:Permissions button.

4. On the Attach permissions policies page, click the Create policy button. It will open a new tab window with the Create policy page.

5. On the Create Policy page, select the JSON tab, paste the following policy code, replace workload_account_id and assumed_role_name with actual value, and then click the Review Policy button.

{
  "Version": "2012-10-17",
  "Statement": {
   "Effect": "Allow",
   "Action": "sts:AssumeRole",
   "Resource": "arn:aws:iam::workload_account_id:role/assumed_role_name"
  }
}

6. On the Review Policy page, give a policy name, e.g. AssumingRolePolicy, and then click the Create policy button.

7. Once the policy is created, come back to the Create Role tab window, search for the new policy just been created, click the checkbox next to the policy name, and then click the Next:Tags button.

8. Add necessary tags, and then click the Next: Review button.

9. Add role name (e.g. AssumingRole) and description, and then click the Create Role button.

Now the configuration in the authentication account is completed. Note down the ARN of the Assuming Role you just created. Let’s get the Assumed Role created in the workload account.

In the Workload Account

Before starting with the Assumed Role creation in the workload account, make sure to have the following items ready :

  • User admin access (IAM full access privilege) to the workload account
  • AssumingRole’s ARN from the authentication account noted down
    e.g. arn:aws:iam::111111111111:role/AssumingRole

Once you have the required information ready, follow the steps below:

1. Log in to the workload account as the user admin

2. Navigate to the IAM page, click Roles on the left panel, and then click the Create Role button.

3. Create a new role by fast tracking through the Create Role Wizard

  • Select EC2 from the Common Services, click the Next:Permissions button (this is a placeholder setting, we’ll come back to update the trust policy at step 9).
  • Click the Next:Tags button to skip the attach policy page.
  • Adding necessary tags, and then click the Next: Review button.
  • Add role name (e.g. AssumingRole) and description, and then click the Create Role button.

4. Once the new role is created, go back to the Roles page, and click on the new role’s name

5. On the Permissions tab, click Add inline policy.

6. On the Create policy page, select the JSON tab, paste and update the following policy code (based on the access the application/service requires), and then click the Review policy button.

{
  "Version": "2012-10-17",
  "Statement": [
  {
  "Effect": "Allow",
  "Action": [
  "s3:ListBucket"
   ],
  "Resource": "arn:aws:s3:::workload_acount_s3bucket_name/*"
  }
 ]
}

7. On the Review Policy page, give a policy name, e.g. AssumedRolePolicy, and then click the Create policy button. Once the inline policy is created, it will return to the role summary page. The new policy should be displayed as an attached inline policy on the Permission tab. The next step is to set up the trust policy.

8. Select the Trust relationships tab, click the Edit trust relationship button.

9. On the Edit Trust Relationship page, paste and update the following policy code, replace assuming_role_arn with actual value, and then click the Update Trust Policy button.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "assuming_role_arn"}
        }
    ]
}

Now the configuration in the workload account is completed.

Testing

Once both assuming role and assumed role are created, the testing can be conducted from the application or AWS service end. This part will vary case by case. We won’t list the details in this article. We will have a separate article that provide detailed information about using AWS Lambda streaming CloudWatch logs to a SQS queue in another account.

You May Also Like

About the Author: Richard Zhao

My name is Richard Zhao. I'm a solution architect and owner of cloudstudio.com.au. Having built knowledge bases for many companies, I'd like to use this cloud studio to share knowledge and ideas with wider people on the internet.

18 Comments

  1. I’m gone to inform my little brother, that he should
    also visit this blog on regular basis to get updated from most recent information.

  2. Thanks for a marvelous posting! I definitely enjoyed reading it,
    you may be a great author. I will be sure to bookmark your blog and will eventually come back from now on. I want
    to encourage you to definitely continue your great job, have a nice day!

    1. Thanks for your support Hwa! Very happy to see that you enjoy reading my articles. I have a list of interesting topics that I’m composing along. If you have any topics that you wish to see, please feel free to post them here. I’ll put them on my list too.

  3. Hi, Neat post. There is a problem together with your web site
    in web explorer, might test this? IE still is
    the marketplace leader and a big part of other folks will leave out your fantastic writing due to this problem.

    1. Thanks for the feedback Effie. I have tried the site on the Edge browser. Seems to be fine. I’ll testes it in IE and see if I can replicate the issue.

    1. Thanks Tessa! I can’t be happier to see readers comment on my articles. It encourages me to keep writing and posting here.

  4. Good web site you have got here.. It’s difficult to find good quality writing like
    yours these days. I really appreciate individuals like you!
    Take care!!

  5. Unquestionably believe that which you stated. Your favorite justification appeared to be
    on the web the easiest thing to be aware of. I say to you, I definitely get irked
    while people think about worries that they
    just do not know about. You managed to hit the nail upon the top and defined out
    the whole thing without having side effect , people could take
    a signal. Will probably be back to get more. Thanks

  6. I have been exploring for a bit for any high-quality articles or weblog posts on this sort of house .
    Exploring in Yahoo I eventually stumbled upon this site.
    Reading this info So i’m happy to exhibit that I have a very good uncanny feeling I came upon just what I needed.
    I most undoubtedly will make certain to don?t disregard this web site and give
    it a glance on a relentless basis.

Leave a Reply

Your email address will not be published.