Centrally Managing your AWS Authentication and Permissions Within a Multi-Account Setup: Part 1

Part 1: Concept and Foundation

Controlling and managing permissions can be very tedious and frustrating for both the end-user and the maintainer. For a single account in AWS, it’s not so bad — you can simply manage it inside the IAM console. You could be discouraged from using multiple AWS accounts as you need to set up permissions and all the users again… and again… and again.

What if I told you that this can be controlled from a central location, deployed via code and there’s no need for multiple sets of credentials, access key pairs, and MFA devices? I highly recommend you carry on reading this blog post…

What happens when you want to start isolating each of your environments to its own AWS account? What about trying to control and grant different permissions for each environment and to different user groups?

• Does that mean having to create new users for each account you have?
• Does that mean you’ll have to re-create user groups, roles, and policies per account?
• Even worse… having to copy and paste policies from account to account?
• What if you need to change a policy for all accounts? You’ll need to sign in and out of EACH account to make these changes?
• What if you have a security audit and require all your keys and passwords to be rotated every three months? Does that mean having to change as many keys and passwords as you have AWS accounts?

The worries are endless and even thinking about it, is exhausting… Not only is this a pain point for the end-user, but it’s also very troublesome for the maintainer and not scalable at all.

The end-user will need to have:

• Multiple sets of credentials to sign in to the AWS console
• Multiple access keys for each account
• Multiple MFA devices (if enabled)

The maintainer will need to:

• Keep having to sign in and out of the AWS console
• Manage all the policies per account

Here at Unibuddy, we have introduced a Centralised IAM system that has granular controls and it’s incredibly easy for our developers to use and the platform team to manage!

The developers will only need to have:

• 1 set of login credentials
• 1 pair of access keys
• 1 MFA device (if enabled)

The platform team will no longer need to:

• Keep logging in and out (Switch accounts — within two clicks to be exact!)
• Updating each account’s policies manually

This will be a three-part series on introducing a Centralised IAM system controlled by Infrastructure-as-Code (IaC):

1. Understanding the Concept
2. Setting up your Centralised IAM
3. Deploying and Managing via IaC

By the end of this series, I’m hoping you will have your own Centralised IAM system completely managed in Infrastructure-as-Code.

Part 1: Understanding the Concept

So, what do I mean by Centralised IAM?

Centralised IAM is a term I use to describe the foundational setup of the entire IAM system inside a multi-account setup. The “centralised” bit refers to the AWS account which we use to store our users and groups which have the permissions to deploy to and manage other AWS accounts. Fundamentally, this is the only account you will ever need to login to, have all your access keys created from, and verify your MFA through.

Services

At a high level, we are going to be using the following AWS services over this entire blog series:

• AWS CDK (Cloud Development Kit — Infrastructure-as-Code)
• AWS IAM (Identity Access Management)
• AWS Organizations (Optional)
• AWS STS (Security Token Service)

Although not mandatory, I would highly recommend using AWS Organizations especially when you have many AWS accounts to manage as it allows you to apply policies across some or all your AWS accounts. You can monitor all activity (via CloudTrail) and manage all your different AWS accounts from a centralised location at a high level. You can choose which services can be used in all of your organisation’s AWS accounts from a central location and more!

Next up, the core service which makes all of this possible: AWS STS.

AWS STS allows you to create credentials that expire with a minimum duration of 15 minutes and a maximum duration of 12 hours. This is useful when you need to grant someone (temporary) permissions to a sensitive resource. For example, debugging a production application. This concept works the same way on both the AWS console and the AWS CLI (your local terminal).

💡 You can tell the difference between a temporary and permanent access key by their prefix. If your access key ID starts with “AKIA”, it’s a permanent key. However, if it starts with “ASIA”, it’s a generated (temporary) key.

To improve security and have confidence in your own system, it’s always best practice to grant permissions on a “need-to-have” basis. What I mean by that is if a user does not need to have permissions to a resource or service, why provide it? Granting more people access to resources means there are more chances of something going wrong unintentionally or, if somehow their credentials have been breached, the hackers will have access to all your internal resources! That’s not good!

When we talk about STS, we need to split it up into two sections; AWS console and the AWS CLI. The reason being is, although they both use the same mechanism, a lot of the nitty-gritty is hidden under the hood when using the AWS console but it’s not so much the case when using the AWS CLI. Traditionally, you would have a pair of access keys (AWS access key ID and AWS secret access key). However, when you use STS on the AWS CLI, you will have to deal with an additional variable called a session token. If all three of these tokens aren’t passed in, your AWS commands won’t work and will receive an “InvalidAccessKeyId” error.

Diving Deeper

Who doesn’t love a diagram, eh?

Figure 1: The Centralised IAM architecture

Throughout this blog, we will use the architecture diagram in Figure 1. We will have an Authentication (auth) account just to allow users to sign in to the console. On top of that, we will also have a Development (dev) and Production (prod) account (you can choose to have more!)

Following this design, you will only create users inside the auth account and grant access by allowing the user to assume a role in another account. When you assume a role in another account, you will no longer have the permissions of the user, but you will inherit the permissions of the role instead. Using this approach, you can allow users to have a different set of permissions for your dev, prod, and any other account!

💡 For a bit of added security, you can set users to only assume a certain role if they have MFA enabled, and more!

Summary

Having a centralised IAM system is much better for both the end-user and the maintainers. You don’t need to have multiple AWS credentials, access keys, or MFA devices and it allows you to be able to quickly gain access to other AWS accounts.

If you are interested in getting this setup or just trying it out for yourself, stay tuned for Part 2: Setting up your Centralised IAM!