Intro

This is intended as an introduction to the AWS IAM account security and permissions system.

Every AWS account has one root user, which is where the billing for the account is managed. However we need to think in terms of companies and not individuals to understand why IAM is so useful. Let us say that we are developing a piece of software that has several different developers, or even teams working on it. We want to be able to give certain users access to some services, but not to others. In this way we can compartmentalize our user permissions.

Permissions are broken down into 4 categories; Groups, Users, Roles & Policies.

Users

⚠️ By default, new users have NO permissions

One of the important things to understand about users in an AWS account is that every user you create belongs solely to this account. There is no type of universal user that can log in and work for multiple accounts. For example let us say I am the owner of a software company called “Greensoft”. If I create new users, all of those users must enter the Greensoft account ID (12 digits) to log in to their IAM account, and every user on the account will use the same account ID. The account ID is available to the root user, and should be provided to you if you are being assigned an IAM user role.

If I was a freelance developer and I was working for multiple companies/accounts, each company would provide me with a different set of IAM login credentials.

That being said, there is a way to combine multiple AWS accounts into an organization. We will not cover that process here.

When adding a new user you will be given the option to allow programmatic access or console access.

Programmatic access gives access ID’s and secret access keys which allows developers to access and modify services through the command line. These are essentially the same thing as SSH credentials, which provides a public and private key, which is then used to remotely connect to a server of some kind. In this case the AWS access ID and secret access keys are the SSH credentials for a user to connect to AWS services remotely.

If you are unfamiliar with SSH I have written a primer here Ncoughlin: SSH Key Tutorial

AWS also provides you with a special login URL for all the users on your account. However I have found that I am able to successfully login as an IAM user without using this unique account login URL. It’s not clear why they provide this unique login URL if they are not going to require it. The only reason I can think of is that you can provide an alias for your account ID and then you can have your company name in the login URL. Totally unnecessary, but possible if you care.

Take note of all this information, the keys especially will not be available when you navigate away. Worst case scenario however, you can make the person a new user if they lose their keys.

Groups

Users can be put into groups. For example you can have an admin group, or a group that only has access to S3 and store files there. Or you could be even more specific and have a group that only has access to one bucket in S3.

If we wanted to create an administrator group we would click on groups, make a new group and then assign it the pre-made policy entitled AdministratorAccess

And this is the essential thing to understand about groups. Groups are given a set of policies, and then users who are assigned to that group are given that group of policies. It’s an easy way to give a group of users all the same policies.

Then you would attach users to that group.

So why would we want to create an administrator group if we already have access to everything as a root user? To start we may want to add additional people to this group. But also administrators will not have exactly the same permissions as the root user. There are some things such as billing that only the root user can access.

It is considered best practice to only use the root user for activities such as billing, and then for day-to-day development activities use an IAM user.

Policies

Policies simply define sets of rules. You can browse the full list of policies in the IAM console.

And if we drill into those policies we can see that they are really just JSON objects! This is useful because one of the nice features of policies is that we can create our own. And in this way you could easily version track your policy changes.

My favorite policy is the administrator policy

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

This policy is hilarious for a couple of reasons. The first is that if we remember that * is a wildcard, this policy is saying “allow any action on any resource”, so we can see with our own two eyes that this policy is completely unrestricted. The second part that is amazing is that this policy has not been changed since October of 2012, which means that they have been using the same policy structure on AWS for almost a decade. Whoever designed that system give yourself a pat on the back.

Roles

By default, no AWS service has permission to access another service. For example if I had code running on an EC2 instance that wanted to reach out to an S3 bucket and store data there, I would need a role that gave it permission to do so.

IAM Security Best Practices

There are a couple of security best practices that it is important to follow with AWS. First let us briefly talk about why security is so important for an AWS account. Hundreds of thousands of people make AWS accounts every year, many of them students and new users who are unfamiliar with the full capabilities of an AWS account. What people need to realize is that an AWS account gives you the ability to start up hundreds of servers and other services that can run up massive bills in a short amount of time. These massive bills can be caused by two main issues.

1. The user doesn’t understand what they are doing
2. The account has been compromised/hacked and is being taken advantage of

We are talking here about the second issue, where an account has been compromised. Even large companies are not immune to this, Teslas AWS account was hacked and used to mine bitcoin. Tesla can take the hit, but a student or small business owner might not. This is why it’s very important to follow security best practices on an AWS account. Do not skip this step!

Multi-Factor Authentication

Most people are familiar with some form of Multi-Factor Authentication (MFA). Google will prompt you to enable this for your email account with either a text message or authenticator app which provide Time-based One Time Passwords (TOTP). In either case it’s a six digit pin that you have to enter in addition to your password.

There is also a new, even more secure method than either of these called Physical Security Keys, also known as Universal 2nd Factor (U2F).

These are physical devices, usually the size of a USB thumb drive. The most popular manufacturer of these devices is called Yubico, although Google has recently jumped into the market with their own devices.

Personally I use a set of Yubikeys to secure all my accounts. The best practice with these U2F devices is to get a set of them, at least three, and to place several of them in secure offsite locations, such as a safety deposit box. That way if one gets lost/stolen or destroyed you will have backups and not be completely locked out of your password manager or Google account.

One of the unfortunate things about AWS is that they only allow you to assign one U2F key to your account, which seems very high risk to me. Simply because of the danger of losing that one key. It has been pointed out to me however that it is possible to recover your root account if your U2F device is lost or destroyed.

AWS Docs: What if an MFA device is lost or stops working?

Another method however that is more middle of the road, is to enable TOTP on your AWS accounts, and then require a U2F device to access the TOTP application. My personal favorite is called Bitwarden which is similar to many of the other password managers like LastPass or Dashlane, except this one is open source.

So in summary, make sure you enable MFA on your Root AWS account, as well as all your IAM accounts that you create.

Delete Root User Keys

It is also strongly recommended that you delete the access keys on the root user account.

AWS Docs: AWS account root user

This is important because these access keys provide completely unrestricted access to the entire AWS account. If these keys were somehow made public it would be the worst security breach possible. Root accounts should not be used for any type of programmatic access anyways. That is what IAM users are for. There is simply no good reason to keep these keys around.

How would these keys ever become public? Well for example someone might commit the keys to a public repository in plaintext. It can happen. I’ll quote a helpful reddit user here:

It’s not uncommon for access keys to be compromised. People make mistakes and accidentally commit them to public GitHub repositories. What if the computer that you’ve downloaded the access keys to gets a trojan? You wouldn’t save your banking account’s username and password to your computer in an unencrypted text file for similar reasons.

Again the fact that you have MFA on your account has nothing to do with your access keys. MFA only protects console logins for the root user. If your access keys get compromised then your yubikey doesn’t matter at all.

I never log in as root in my personal accounts, ever, just to be extra safe. It’s best practice to create an IAM user and log in as that user. You can even view billing information with IAM users now if you enable this for your account. There is really no reason to log in as the root user unless you’ve done something dumb and locked yourself out of something in your account. There is definitely no reason to ever generate access keys for the root user. I work in cloud security for a software company and the just the thought of root access keys makes me cringe.