Centrally managing your AWS Authentication and permissions within a multi-account setup: part 2

Part 2: Setting up your Centralised IAM

Hurrah! You’ve made it to part two of this series!

In this post, we look at how to implement the organizational architecture from Part 1. If you haven’t read Part 1, I would highly recommend you do so first to help you understand the foundations of this concept.

Prerequisites

• Basic understanding of AWS
• Basic understanding of what IAM policies do
• aws-cli installed

Note: Avoid using the root account as it has elevated privileges compared to the other accounts in your AWS organisation. The root account should only be used for emergencies.

Recap

So far, we’ve gone through the concepts of the Centralised IAM system, its pros and cons, and how it fundamentally works under the hood. Now, we’re going to get down to business and try to implement this system.

AWS Organizations

If you chose not to use AWS Organizations, you can skip this section but note down the account IDs of each account as you will need them later on.

1. Head over to the AWS Organizations console
2. Click Add an AWS account
3. Choose a name for your account, such as development
4. Click Create AWS account
5. Remember to note down the account IDs as you will need them later on. You can also go to the Organizations console to find the account IDs
6. Repeat these steps for the production account and your authentication account too

Understanding the IAM policies

To enable Assume Role across AWS accounts, we need to have both accounts set up to communicate with each other. In this section, I will be showing you how to access the Dev account. This will work with any other AWS account too, so you can simply replicate these steps to each respective account you wish to access.

• For the Auth account, we need to allow users to access the STS service (more specifically the sts:AssumeRole action)
• For the Dev account, we need to add the authorization account’s ID to the role’s whitelist

So let’s have a closer look at the IAM policies we need to apply.

Authentication (Auth) Account

This policy will be applied to either a user or a group in Account A:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DemoAssumeRole",
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::<dev account's ID>:role/cross-account-role*"
            ]
        }
    ]
}

What we’ve done here, is grant this user or group permissions to use the sts:AssumeRole action on a role in the Dev account called cross-account-role (You can name this whatever you want — it just needs to match)

You can also leverage wildcards in your IAM policy

Development (Dev) Account

This policy will be applied to the cross-account-role in the Dev account as a Trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DemoAssumeRolePrincipal",
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<auth account's ID>:root"
            }
        }
    ]
}

The Trust relationship defines what entities can assume this role. So we have allowed only the Auth account to action sts:AssumeRole on this role. From here, you will not inherit the permissions attached to the cross-account-role role.

If you are unsure on how many entities will need to access this account, we can use the “root” keyword which will refer to any entity in the specified account

Setting up your Account

Authentication account

1. Go to https://console.aws.amazon.com
2. Click Root user and sign in using your Authentication account's root email (If you followed the AWS Organizations section, it's the email you entered in Step 3)
3. Create your own user and grant it sts:AssumeRole permissions

Here’s a brief instructional guide on how to do so in the AWS console:

1. Create a new user with AWS Management Console access

2. Select “Attach existing policies directly” and “Create policy”

3. A new window will pop up. You will need to fill out this form

Service: STS
Actions: AssumeRole
Resources: The ARN of the role in the development account

4. Give your policy any name you like (Try making it as specific as possible!) and hit “Create policy”

Return back to the previous page and hit the little refresh icon on the top-right hand corner of the policy box

5. Search for your policy name and select it, click “Next”

Follow the instructions through and click “Create user”

Remember the username, password of this new user and the account ID as will need it later on in this tutorial!

Development account

1. Log in to the root of your development account and go to the IAM console
2. Same as the authentication account, enter your account root email
3. Go to the Roles tab and click Create role

1. Select your trusted entity to be “Another AWS account”, enter your account ID and click “Next”

Account ID: The account ID of your Authentication account

2. Here, you will grant permissions to the development account

If you just want to test things, you can select AdministratorAccess which will grant full permissions to the Development account.

Otherwise, you can create your own custom policy by clicking “Create policy”

Follow the instructions to the end again and click “Create Role”

That’s it, you’re all set up and ready to test the Assume Role!

Testing the Assume Role

For demonstration purposes, I will be hiding the real account IDs that I’m using.

AWS Console

After setting up the above policies, you can test whether it is working via the AWS console

1. Go to https://console.aws.amazon.com
2. Select IAM user, enter the authentication account's ID, the username and password of the user you created before in Step 3 of Authentication account
3. Once you have successfully logged in, go to the dropdown menu in the top-right corner (where your username is) and click Switch Roles

This is the form you will fill out to Switch Role

Account: The account ID of the Development account
Role: The name of the role you created above in the Development account
Display name: (Optional) For your own browser to allow you to identify which role you’re switching into

Switch Role data is saved per local browser and saves your last 5 roles

I highly recommend using a third-party browser plugin that I’ve found extremely helpful called AWS-extend-switch-roles.

All credits go to tilfinltd who created this plugin.

Click “Switch Role”. If you are successful, you will be redirected to the AWS console page inside your Development account

You can verify this by clicking your username at the top-right hand corner and the Account ID should match your development account’s ID

Congratulations! You’ve successfully set up your Centralised IAM!

AWS CLI

Similarly, you can also test this via the AWS CLI. You can read more about your local .aws files from the official documentation.

Go to your user inside the IAM console in your Authentication account

You may need to login as the root user again

1. Click the “Security credentials” tab and you will have the option to “Create access key”

Go to your local terminal and run aws configure

AWS Access Key ID: Paste in your access key created above
AWS Secret Access Key: Paste in your secret access key created above
Default region name: Leave empty or enter your AWS region (e.g. eu-west-1)
Default output format: Leave empty or choose valid options (e.g. json)

These will save your credentials into your local system: ~/.aws/credentials

Open up your ~/.aws/config file (or create it if it doesn’t exist). Edit your configuration and it should look something like this:

[profile dev]
region = eu-west-1
role_arn = arn:aws:iam::123456789012:role/cross-account-role
source_profile = default
[default]
region = eu-west-1
source_profile = default # Name of profile in ~/.aws/credentials

Using your updated ~/.aws/config file, we will now test this with s3:

Lists the S3 buckets (Authentication account)

We will now use the--profile flag to tell the aws-cli to use your dev profile credentials

Lists the S4 buckets (Development account)

Summary

We’ve learned how to set up our Centralised IAM system for both the AWS Console and the AWS CLI. We currently only have two AWS accounts but this can be expanded onto as many AWS accounts as you want or need. And we’re only using one set of credentials and one pair of access keys to be able to access all the whitelisted accounts.

This is a good step in the right direction, but how can we view a single source of truth? Or if we had multiple AWS accounts, how can we change all the policies without having to go into each individual account?

The answer is Infrastructure-as-Code. Stay tuned for Part 3: Infrastructure-as-Code!