Prerequisites

• Your Admin user credentials

The Lesson

Today we will learn about AWS IAM Roles, which are different than ‘roles’ you have probably seen before. It’s technically a valid use of the word, but any of you coming out of the Microsoft world, in particular, will need a sec to change how you think about ‘roles’. Let’s start with some IAM background, and then show how it applies to roles in AWS.

In our first IAM lab, when we created our admin user, we started IAM fundamentals with a few important definitions:

• Entity: a person or ‘thing’ which has 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, such as “[email protected]”.

• Identifier: a means by which an identity can be asserted.

If you’ve done all the labs so far, you are an entity, your root account email is an identity within the namespace of all AWS, and your admin IAM user is an identity within the namespace of your AWS Account. One entity with two identities.

The problem with that admin IAM user is that it is a darn IAM user.

IAM users have three really big problems once you start scaling beyond a personal AWS account. Meaning IAM users are the source of something like half of all AWS compromises.

• An IAM user has static credentials. A username and password combination for logging into the console, or an Access Key and Secret Access Key for API calls. Attackers just love static credentials — they are easy to accidentally expose, steal, or leak. It happens. A lot. Ask me how I know. If you dare.

• An IAM user has static permissions. We try and set them for least privilege, but it turns out that ends up being the least privileges someone might ever need — not the least privileges they need at that moment.

• An IAM user isn’t necessarily a person. It’s also the primary mechanism for getting API credentials to allow code or systems from outside AWS to access resources or services inside your AWS account. This means anyone cracking that external app or system can now use those credentials to do bad things.

Here’s how it works in practice. If you need some basic privilege most of the time but might need admin privileges in an emergency, you need to have either a) one IAM user with full admin rights all the time, or b) two different IAM users with different credentials — and log in using the correct account with the appropriate rights for what you're doing now, and switch whenever you need either more or less privileges.

This is how we end up having a lot of usernames and API credentials scattered all over the place. Especially once we start building cloud native applications, where parts of our application talk directly to AWS services and need their own credentials. And unless you use advanced defenses like a data perimeter (which I can’t wait to get to!) once an attacker has those credentials, they can use them from nearly anywhere.

But what if there was a better way?

I mean, of course there is… you would’ve noticed if the title of this lesson was “You are totally screwed, hahahahahahaHAHAHA!”

In AWS the answer is an IAM Role. The easiest way to think of a role is as a set of permissions you can use for a time-limited session. In our IAM terminology, this is a persona.

• Persona: the expression of an identity, with attributes that indicate context.

Roles are personas. All of you have used systems where your role is “user” or “admin” or “something else”. On the back end that role — that persona — is tied to a set of permissions. In many systems this is exactly how it works: user [email protected] logs in and can have the admin role in one environment, and the read-only role in another.

Here’s a diagram:

AWS is a little more complicated, because while the core concept of a role is the same, the implementation is very granular and flexible, and used all over AWS, including by their own services. A role is an AWS core primitive, and even Amazon services need to use them and play by their rules.

TL;DR: AWS IAM roles allow us to use different sets of permissions, and temporary credentials, instead of only one set of permissions and static credentials. Unlike roles you have used in many other systems, you can change your role on the fly based on what you need to do at that point in time.

Phew. Got it? Because this is really important. Let me break it out more directly:

• An AWS IAM role is a container for permissions.

• You must assume a role to use it (and have permission to use that role). This is a deliberate act (API call).

• When you assume a role, AWS assigns you a set of temporary credentials which work for a time-limited session. This is great because it gets rid of static credentials.

• A role also has rules about who or what can use it. This is a different policy than the permissions policy, called the trust policy.

Here’s a feeble attempt at another diagram:

Roles largely solve our two problems:

• We get rid of static credentials.

• We can assume different roles (personas) for different tasks for specific time periods. We don’t need a new username/password for every user and permissions combination.

Roles are fricking awesome. Mature cloud organizations rely almost exclusively on roles, and get rid of nearly all IAM users. This eliminates a wide swath of potential attacks tied to lost, stolen, or abused credentials.

Today’s key points are:

• IAM users are bad because they rely on static credentials and permissions.

• IAM roles are good because they use temporary credentials, and one identity can use different roles to access different permissions.

• An IAM role is how we change our persona. Not personality — that’s all you, Boo.

• AWS uses IAM roles for everything, including its own services.

One last note: even as we start down the path of using roles and getting rid of IAM users, I still recommend at least one non-root admin IAM user in your main account. This will allow you to go in and fix things (especially broken federation connections) without breaking out that super-sensitive root account. Not everyone operates this way, but I do.

The Lab

Today we will create our first IAM role. We won’t use it yet, but it will come in very handy later. This role will allow EC2 instances (virtual machines) to connect to a service to manage those instances, and let us log in without mucking around with SSH keys.

This lab is meant to cover the basics and show you the flow in the AWS console. We are going to create a lot of different kinds of roles in different ways throughout many of our labs, so I picked one of the simpler options to start with. The entire process should only take a few minutes.

Video Walkthrough

Step-by-Step

First, go to https://console.aws.amazon.com and sign in. Then check your region and make sure it’s set to Oregon. Does it matter today? Nope — IAM is a Global Service, which means it works across all regions. Like most global services it’s actually running in us-east-1, so we’d all better hope there isn’t an asteroid strike in northern Virginia. (Although that might have some social benefits).

Then go to IAM. Pretty soon I’ll start skipping this screenshot on how to navigate to different services. You have been warned.

Then click Roles and Create role:

The first thing we need to do is pick the Trusted entity type. This defines who or what can assume the role. Today it will be the EC2 service (the one which handles instances/virtual machines). In other labs it will be different AWS services, a federated identity provider, or even an IAM user.

This first part of the console wizard builds out the Trust Policy which, going back to our diagram, is where the rules for who or what can use the role are defined.

Since we are creating a role for the EC2 service to use and assign permissions to instances, we’ll go with the default option: AWS service.

The Use case dropdown is designed to help focus you in on what you plan to use the role for. This is still all about filling in the details for that role trust policy. Click the dropdown to see the options.

Yep, it’s a big ole list of most of the different AWS services. You’ll notice that the most common are EC2 (again, instances, which is what Amazon calls virtual machines) and Lambda, which is the service for running serverless functions. Lambda functions are code you load up that AWS runs for you, without you needing to worry about pesky things like operating systems. Pick EC2.

Since there are many reasons we might want to create a role for EC2 instances, the AWS console lists the most common ones we can pick from. This will just load up the recommended permissions policy. Remember, this is a console wizard designed to make things easy. These aren’t all the options, and you can write your own trust and permissions policies from scratch when you need to do more.

Pick EC2 Role for AWS Systems Manager.

Then click Next in the lower right corner.

Here’s where the console wizard does the work for you. It loads up the permissions policy we use to let an instance talk to the SSM service. This is the AmazonSSMManagedInstanceCore policy. Doesn’t that just roll off the tongue?

If you click the plus sign you can review these permissions. Or you can click the drop-down and see it inline. Here’s what it looks like:

Okay, you have 8 seconds to memorize those! Nah, we will cover permissions in the next lab (and many others). There’s nothing to change here, so look at it awkwardly for a few seconds and click Next.

The next page ties it all together. First, set the Role name to SSMInstance. Please use the names I recommend, or you may get lost in later labs.

Just below that you can see the JSON of the Trust Policy. We will cover the AWS policy language in the next lab, but this one is pretty easy to read. It says that the ec2 service is allowed to assume this role.

Keep scrolling down and Create role. We don’t need a tag for this one.

The next screen shows all the roles in your account, and you can see that AWS created 2 of them when you first set up your account. These are special roles called service linked roles, which we will cover later. Our new one is at the bottom.

If you click the role you can see its details. The key parts of this page to understand are the ARN (Amazon Resource Name, the unique name for this role in AWS), the instance profile ARN (we will also cover this later), and the tabs for Trust and Permissions policies. Those two policies are the real meat of a role, as we discussed back in the beginning.

If you look closely you’ll see the Maximum session duration. Remember how roles are containers for managing permissions for a session? That includes how long a session lasts.

Key Points

• An AWS IAM role is a container for permissions.

• Every role has a trust policy which defines who or what can use it, and even AWS services require this policy to use a role.

• The role also has a permissions policy which defines what it can do.

• To use a role we assume the role, which creates a session.

• Credentials are specific to a session, so roles do not have static credentials.

• Users can change roles on the fly (if they have permission to use the role to be assumed), which enables users to switch personae.

• An instance profile is an extra thing used to connect EC2 instances to roles.

-Rich