Access Management For Your Personal AWS Account

Signing up for an AWS account is easy. But how do you get started securely? Let’s take enterprise level access management down to the personal level.

Photo by Cristina Gottardi on Unsplash

Signing up for an AWS account is super easy. All you need is an email address and a credit card. But then there are pages and pages of docs advising many best practices for all aspects of managing and using your AWS account (have a look at the number of links off this blog post).

One thing I haven’t really seen is an example of how you can set up access to your personal AWS account with many of those best practices included. I emphasise “your personal” AWS account because work related AWS accounts often have higher security requirements and connections to corporate Active Directories and so those solutions don’t easily translate to the context of a personal AWS account.

So one weekend, I thought I’d play around with my AWS account and see if I could easily develop a serverless application using an IAM user with non-destructive permissions (read-only) and temporarily assuming roles with more privileges when needed.

Why does this matter?

There are many blogs and docs that go into the reasons as to why securing access to your AWS account is important. The consequences for getting it wrong mainly relate to $$.

Requirements

The best practices say to only use your Root User account to create an IAM user for everyday use. After this point, it’s then up to you how you choose to configure and use that IAM user. I added these further requirements:

• One IAM User with the minimum required permissions
• Any privileged actions require temporary assumption of a role
• Assuming roles with elevated permissions requires Multi-Factor Authentication (MFA)
• Minimal extra set up or configuration

These requirements echo the same principles we use to manage our enterprise AWS accounts, namely the principles of Least Privilege, minimising passwords/keys, and requiring MFA for privileged actions.

Let’s get started!

There are two main ways to access your AWS account:

1. AWS Console in your favourite browser
2. AWS CLI in your favourite terminal

Whichever way you access your AWS account, the first step is to set up your IAM User, Group, and Role(s).

IAM Set Up

Let’s imagine you’ve just signed up for your AWS account. You’ve entered in your email address to be associated with your Root User and your credit card details with the hope that the charges stay small.

The first thing to do is secure your root user account according to the steps here. TL;DR:

1. Do not create AWS Access keys
2. Set a strong password and lock it away securely
3. Set up MFA

At this point, the docs become a bit theoretical, so continue reading for a walkthrough of the setup I ended up with to achieve those extra requirements I detailed at the start of this post.

I’d like to add that this is just one way to configure access to your AWS account. It won’t be right for every situation, and this blog is not intended to herald it as the solution to all security nightmares. It is simply one way I ended up setting up my AWS account that seemed pretty cool.

1. Create an IAM User with minimal privileges

Log into your AWS account with your Root User (I’m assuming at this point this is a brand new AWS account, if you have an Admin IAM user then use that instead!)

Go to the IAM console and click on Groups. Create a new Group called Viewer and attach the AWS Read Only managed policy.

The reason I advise creating this as a group is that in the future you may want to grant someone else access to your account or maybe you’ll want another User login for some reason. Having a group with these minimal permissions will make the creation of those further accounts a little simpler.

Now go to Users. Create a new user with the username that you want to use to login to your AWS account from now on. Set up a strong password, set up MFA, and add the user to the Viewer group you just created.

2. Create a privileged Role

Now go to Roles and create a new Role with the permissions that you expect you’ll need.

In this example, I’ll assume you want to create an administrator role called ‘Admin’ but it doesn’t have to be. If you know the services you’ll be working with you can select the appropriate permissions for those services.

While creating the role set up the Trust policy to only allow your IAM User to assume the role.

The reason I point it to the IAM User and not the Group is because you may forget that it’s set up that way and accidentally give a new user the ability to assume Admin rights to your AWS account. Granting of privileged access should always be a deliberate act.

Also, set up the Role to require MFA authentication.

This means that in order for you to receive temporary credentials with Admin permissions, you have to prove that you are who you say you are, via a second device. So if the AWS keys for your IAM user are compromised, the worst thing an attacker can do is look through your resources (and you can limit this further if you wish) unless they also have your MFA token.

The important reason as to why you’re creating a Role is that Roles are assumed temporarily. By default, the maximum session time for a Role is 1 hour. That means if the AWS access keys you receive become compromised, they are only valid for a maximum of 1 hour. You can increase this of course but it is so easy to switch in and out of Roles that you may find 1 hour is more than sufficient, as you’ll see in the following sections.

End of setup

Now you have an IAM User with minimal permissions that can temporarily assume a privileged Role when you need to do anything above viewing resources.

You can now log out of your Root user account and log in to your IAM User.

The following sections will show you how assuming the privileged role works in the AWS Console and AWS CLI.

AWS Console Access

Switching Roles in the AWS Console is quick to set up the first time and then really easy to use after that — and you can colour code different Roles!

Here are the official AWS docs on how to do it: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

If you have access to the IAM console, then navigate to the Role you want to assume and click on the provided sign-in URL. This takes you to the “Switch Role” screen where you can enter in a custom display name and pick a colour!

If you don’t have access to the IAM console with your IAM User, then first take note of your AWS account number (or AWS Account Alias) and the Role name that you want to assume.

Then click on your username at the top right hand side of the header and select “Switch Role” from the drop down menu.

This also takes you to the “Switch Role” screen, but you need to fill in your AWS account number and Role name yourself. Then enter in a display name that makes sense (I just use the same Role name), pick a colour and you’re done!

Coloured icon showing I have assumed the Admin Role

You know you have successfully assumed your privileged Role when you see the display name and coloured icon in the top right hand side of the header where your username was.

To switch back to your IAM User, just click on your username again and select “Back to <your username>”.

Once you set up a Role to assume it stays in your username dropdown so you can quickly assume it in the future (assuming you re-use the same browser).

AWS CLI Access

Switching Roles when using the AWS CLI is much easier than you might think!

Here are the AWS docs on how to configure the AWS CLI to automatically assume a role for you based on the --profile you select when running CLI commands: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html

By specifying a role_arn and a source_profile in your ~/.aws/credentials file, the AWS CLI has all the information it needs to use the AWS keys in your source_profile and make the aws sts assume-role call on your behalf to assume the specified Role.

This supports both MFA and/or ExternalID requirements. If you configure the MFA serial from your IAM User profile in your ~/.aws/credentials file then the AWS CLI will prompt you to enter your token code whenever you run a CLI command and pass the --profile parameter selecting the Role requiring MFA authentication.

If you require an ExternalID to be provided then you can configure this in your ~/.aws/credentials file as well.

Quick case study on getting started with Terraform

I mentioned that I ended up with this configuration while playing around with my AWS account one weekend.

The reason I was setting up my account was to learn more about Terraform in the context of wanting to create a serverless application. To get started with Terraform I wanted to host the state in S3 and manage state locking in a DynamoDB Table. In order to do that, I first had to create those resources which requires extra privileges.

I already had my IAM user with viewer permissions, so I logged into the console and assumed my ‘admin’ role so I could create a new role to use with Terraform.

I named the new Role ‘terraform’ and gave it most S3 and DynamoDB permissions but restricted it to resources starting with my chosen project name.

I already had my IAM User credentials configured as the default profile in my AWS CLI so I just added in a terraform profile to my ~/.aws/credentials file that was configured to assume the ‘terraform’ Role and prompt me for an MFA token when I ran terraform apply .

There is actually a bug with the AWS Terraform provider where it can’t prompt you for an MFA token, so I had to switch to providing an ExternalID and storing that securely to pass in as a tfvar in the terraform apply command.

So, as I develop my project using terraform, all I have to run is the standard terraform apply command and behind the scenes it:

1. looks up the terraform profile in my ~/.aws/credentials file,
2. does the aws sts assume-role call with the provided ExternalID,
3. uses those temporary AWS credentials to plan and apply any changes to my terraform stack.

At the end of the day I had:

• One IAM User with minimum permissions to my AWS account
• Any privileged actions required temporary assumption of a privileged role, either the ‘admin’ or the ‘terraform’ Role, depending on what I was doing
• Assuming roles with elevated permissions required Multi-Factor Authentication (MFA). In this case the elevated permissions for ‘terraform’ required that I was running the command as my IAM user and that I also passed in the correct ExternalID.
• Minimal extra set up or configuration — the only extra step was to add the ExernalID to be passed in as a tfvar on the terraform apply command.

Note: Requiring an ExternalID is not the same as requiring MFA. It is less secure as it is not guaranteed to be stored on a physically separate device/system, but it is at least an extra layer of protection.

Conclusion

Securing your personal AWS account can be daunting to new AWS users, even experienced AWS users who have access to enterprise setups but haven’t tried to translate those to a context without Single Sign-On and managed AD.

I hope this blog helps pulls together the relevant features of AWS’s IAM service and tools into a setup that is easy to configure securely with no extra tooling required. All the features are already built into the AWS Console and CLI — the difficulty is often identifying which ones tie together in a holistic way.

Nicole Yip is an Engineering Manager at the LEGO Group in the team building LEGO.com. She leads the Platform squad who enable product focused squads to build awesome things.