Prerequisites

• Your AWS account

• The Authy iOS or Android app on your phone

• Your root account credentials

The Lesson

It’s time for “the talk”.

You know, when the more-mature cloud security expert sits you down to discuss the wonderful but sometimes-scary world of… IAM. It’s really important that you make good decisions, so IAM can be a vibrant and healthy part of your cloud security life.

Developing a deep understanding of cloud Identity and Access Management is the single most valuable investment you can make in your personal skills. It’s been said (by me) that all cloud security failures are IAM failures and all IAM failures are governance failures. Sure, absolutes are absolutely garbage, but once you understand why IAM is so critical it will all click into place.

You hear phrases like “identity is the new perimeter” that don’t really go into why IAM matters so much, but it’s actually pretty simple. In public cloud, all administrative functions, down to the virtual equivalent of network wires, is unified into a single management plane. This management plane is accessible on the Internet, and protected with little more than a username, password, and (maybe) MFA.

The rest, and there is a lot of ‘rest’, is just details. Every interaction with the management plane is governed by IAM, and this quickly increases complexity exponentially. The single biggest source of successful cloud-native security attacks is some form of exposed or abused credentials and/or misconfigured IAM permissions. From cloud ransomware to crypto mining to SSRF, the core of the attack come down to IAM.

So we will spend a lot of time on IAM. Like, years. But the good news is we will cover the fundamentals that can keep you out of the worst trouble in the first few months. As we go along I will introduce some fundamental concepts alongside the practical labs. Also keep in mind that we are focused on AWS, and each cloud provider — especially Azure — has a different IAM model.

Today I want to start with three basic definitions, taken right from the Cloud Security Alliance Guidance, before we get into hands on.

• Entity: the person or “thing” that will have an identity. It could be an individual, a system, a device, or application code.

• Identity: the unique expression of an entity within a given namespace. Email is the best example of this: [email protected] means I am rmogull in the securosis.com namespace. Remember you had to use a unique email for your root account? That’s your unique identity across all of AWS.

• Identifier: the means by which an identity can be asserted. This often traces back to a cryptological token, like a session token. We’ll spend a lot more time on these later.

This background is important because today we are going to add a second identity in a different namespace. Your root account is the email you signed up with, and that is unique across all of AWS (and the Internet) globally. It’s also unique across time, since AWS only allows you to use that email once and it is forever tied to this account. Now we are going to create an IAM user which is a unique identity, but only within your AWS account.

In AWS an IAM user is a core ‘primitive’. Primitives is a term for low-level building blocks, but not one used in AWS documentation. An IAM user is simply an identity you create and manage within the namespace of your AWS account. For example, I’m “rmogull” in a few dozen AWS accounts. I get to use that name because it is the only rmogull in each account, and if I go to use it somewhere else I need to use the full path to that name which prepends my account ID (a simplification, but we will talk about Amazon Resource Names later).

IAM users are kind of dangerous because they rely on static credentials. Either a username and password for console access, or Access Key/Secret Access Key for API access. Static credentials are easy to steal and misuse, so we always try to avoid them, and we will spend a lot of labs on that later.

Today’s key points are:

• An identity is a unique representation of an entity within a given namespace.

• In AWS, the root user is unique in the namespace of “the Internet”: root accounts must use an email address, and you can’t use the same one to be root in another account.

• An IAM user is an identity within your AWS account. So the name “rmogull” can exist in every AWS account. Please note that if you do that, you must pay me for a license.

• IAM users don’t have to be users — a user is just an identity with static credentials and can represent code, a computer in your datacenter, or whatever.

• Other cloud providers have their own versions of this, but IAM is so darn complex we will stick with AWS for now.

The Lab

Hopefully I scared you so much last week that the mere thought of using your root account causes you to pass out, wake up, crawl into a box, and curl up in the fetal position murmuring “make the bad IAM go away.”

After today there will be only 2 reasons to use the root account:

• For one of those last lingering PITA services or API calls AWS requires it for

• In case you lose control of an admin user and need to kick out an attacker

For day-to-day operations you will use the full-admin user we are about to create. Although you often hear that you shouldn’t have any IAM users in AWS they are sometimes unavoidable. Way down the road we will get into federation and you won’t need this user anymore, but you always want one full admin IAM user in every AWS account!

Why?

Because what if your federation breaks later? This has happened, a lot. Having a break-glass IAM admin allows you to access the account without using the root account.

Now this is a little debatable. Some places prefer to use the root account for break-glass so they don’t need an IAM user. Personally I tend to lock out the root account using techniques we will cover later (an SCP). That said, I manage hundreds of accounts and have some better techniques for access, but usually create an admin user in the more important ones where when something breaks, I need to be able to get in fast.

All that is neither here nor there because we don’t have any federation now and are only working in a single training account, so a full-admin IAM user will be our only option once we fully lock down the root account.

The process will probably take less time than reading all this:

• Log in with your root account.

• Go to IAM.

• Create a new group called “Administrators” and apply the “AdministratorAccess” managed policy (we will spend a ton of time on policies later).

• Create a new IAM user.

• Save the password.

• Log out of your account.

• Log back in as that IAM user.

• Add MFA (using the Authy app or the virtual MFA of your choice, which you should already have installed).

And now for the step by step:

Video Walkthrough

Step-by-Step

First, got to https://console.aws.amazon.com and sign in.

Then click in the search box and type IAM.

Then click User groups or Groups — either works. We’ll start with a group in case you want to add more users later. Even when you are trying to minimize IAM users, this is a better practice than attaching policies directly.

Click Create group. Name the group “Administrators” and then attach the AWS “AdministratorAccess” policy. This is a managed policy built into every AWS account.

We will go deeper into policies later, but it’s just JSON for “Allow all actions on all resources”. Not that it really means “all” because AWS has a few things they require you use the root account for still (rare, but enough to be annoying).

Then scroll down and click Create group.

Now click Create user to create the user account. This will be your user account, so you have something other than your root account to work with.

I generally recommend first initial and last name, then make sure you validate you want an IAM user (remember, I said they are dangerous and AWS agrees), then set a strong password and un-check the box requiring you to change the password on next login! That’s what you use when you create one of these for someone else, but you are smart security people using a strong password from your password manager, so it isn’t a problem.

Now choose to add the user to a group and select our new Administrators group. This means the user inherits the AdministratorAccess policy, which is our objective.

On the next page you may want to capture the sign-in URL because you need this, or your account ID, to sign into this new IAM user. Remember: the IAM user exists only in your account so AWS needs you to tell it which account to use. Interestingly enough this is not true for API credentials. Those (an Access Key and Secret Access Key) are unique and don’t need you to embed your account ID. We will talk about them more later, but it makes sense. “rmogull” could be anyone. AKIA734957XYZ generated by AWS (an Access Key) is unique.

A good trick is to keep this sign-in URL in the notes field of your password manager.

Now pop down the menu in the upper-right corner of the console and click Sign Out. Then paste that URL into your title bar to go right to the login page for the account you just created. If you forget that URL you can go to the regular sign-in page and use either your account ID or account alias (which we haven’t yet set up).

Once logged in, click to pop down the menu in upper-right corner, and select Security credentials.

One of the things you see on this page is your Amazon Resource Name (ARN). Everything in AWS has an ARN, which is a canonical address unique across all of AWS. As you can see, it has your account ID embedded in it, then the service, then the resource type, and then the resource. The canonical ID is more of a unique cryptographic identifier, where the ARN is the human readable version.

Having a canonical ID is important because we re-use human readable names, like usernames and “ProdServer”. AWS needs to make sure you don’t do things like delete a user, then someone else recreates one with the same name and get all the privileges of your user.

This goes back to our explanation of how an identifier is the unique representation of an identity in a namespace. Good identifiers aren’t reusable, and AWS handles this with both crypto-stule canonical ID, and a version mere mortals can read and remember.

For our last step, repeat what we did with the root user and set up MFA. Don’t skip the MFA! This full admin account is nearly as powerful as your root account, and losing it means an attacker would totally own you!!! I won’t repeat all those steps, and it’s straightforward.

And Lab 2 is in the books!

Key Points

• An entity is a person or thing.

• An identity is the representation of an entity in a given namespace.

  • Today we created an identity representing you in the AWS account as an IAM user (your account owns the user). Last week we created an identity representing you across all of AWS.

• An identifier is a unique digital representation of an entity. We looked at the ARN, which we can read, and the canonical ID, which is more unique for AWS itself to read (usually they are some kind of hash or token).

• You should use this full-admin user instead of your root account from now on. The root account is ring 0, this user is ring 1, and so this lowers your risk in case this account is compromised.

This is the first part of our foundation for IAM and we will spend a lot of time in future labs digging into all the bits we breezed through this time.

And that’s it! The video walkthrough is always up at the top if you need it. See you next week.

-Rich