Just a quick note: we are starting to get into more complicated topics which can get a little confusing. Please send any feedback to [email protected] — I really want this content to be accessible even for newer folk.

Prerequisites

• Established your organization

• Created your Security OU

• Created your SecurityAudit account

The Lesson

CloudTrail again, you say? Already?

Yep. But now with a twist. In the next few labs we will combine multiple new skills as we centralize CloudTrail logs in another account, do something in our management account, and then learn how to find that activity in logs.

Along the way we will learn new skills and concepts:

• How to assume a role into another account

• How to write a resource-based policy

• How to create an organization-wide CloudTrail

• How to store those logs centrally

• How to read the logs and identify activity

As I write this I think it will only take 3 short labs to get through all those topics. We won’t cover every nuance — just enough to get started, and we’ll return to each topic later.

This week we will learn 2 basic skills and a few important security tidbits about each:

• How to assume a role into another account

• How to create an S3 bucket

Assuming a Role

Way back in Create Your First IAM Role we added a new role we will later use for EC2 Instances (virtual machines). If you recall, we described a role as a temporary container with two sets of permissions:

• An IAM permissions policy which grants the role entitlements (what the role is allowed to do)

• A trust policy (who is allowed to use the role)

Then, when we created our Organization, I mentioned that every account we create has the OrganizationAccountAccessRole which allows us to log into sub-accounts from the management account. We call this assuming the role and the API call we use is sts:AssumeRole. “sts” is the Security Token Service:

In this lab we’ll swap roles in the AWS console, so you won’t see the API call, but pretty soon we’ll hunt it down in the logs to see what it looks like. Remember we don’t have a user account in our SecurityAudit account so we have to assume a role to move into that account and do anything. Here’s how it works:

• The user or role must have IAM permission for sts:AssumeRole. We will use are administrative user which has full ‘*’ permissions, so no problem there.

  • Important note: AWS does not allow you to assume roles from your root user account — you need to use an IAM user or another role.

  • Roles can assume other roles; we call this role chaining. We’ll come back to it later.

• The user or role also needs permission in the destination role’s trust policy. Here’s what that looks like for the OrganizationAccountAccessRole we’ll use in a minute:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::201743012353:root"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

Remember, this is the policy attached to the role in our SecurityAudit account which we will jump into. The human translation of this JSON is “allow anything or anyone from management account number 201743012353 to use this role”. Yeah, it’s weird, because it looks like it only lets “root” assume the role, but it really means “everyone but root since root can never assume a role”, and I strongly suspect AWS totally regrets hiring the developer who came up with that format.

• The user/role makes the API call to the Security Token Service to assume the role. If all permissions line up sts sends back a temporary set of credentials which only work for a limited period of time (session). The default is an hour.

• In the console this all just happens and you don’t see the credentials. If you use the command line tool or APIs you then need to switch over and start making API calls with the new session credentials.

• Once the session expires you need to renew the credentials. The console will usually do this for you automatically for up to 24 hours.

• You can also make the AssumeRole call with parameters for different session lengths and some other things. We won’t mess with that until we get to command-line stuff.

Here’s a visual:

To keep this from getting long we’ll talk more about S3 and basic S3 security in the next lab. All you need to know this week is that S3 is a place to store files (which we call objects), and we store objects in buckets. Just think of a bucket as a shared directory.

Lesson Key Points

• Assuming a role allows an IAM user or another role to use a different set of permissions for a time-limited session.

• We can assume roles across accounts, which is the way we do things in a different account after logging into the first account.

• In order to assume a role you need IAM permission for sts:AssumeRole and to have permission in the role’s trust policy to use the role.

• When you assume a role the Security Token Service gives you a set of time-limited credentials.

The Lab

Our focus today is learning how to assume a role in the AWS Console. We’ll move from our management account into our SecurityAudit account, and then create an S3 bucket, which we will use later to centralize all CloudTrail logs for the entire organization.

Video Walkthrough

Step-by-Step

First go to https://console.aws.amazon.com and sign in. Then get the name of the current S3 bucket holding your CloudTrail logs, here in the management account. Go to CloudTrail, click Trails, and copy and paste the S3 bucket into a text file (I call these my Cheat Sheets, not that I would ever cheat at anything — especially not poker, especially when you and I are playing for cash):

Then on your cheat sheet change the last part of the name to something different but still random. S3 bucket names need to be unique, globally across AWS, so this avoids name conflicts. You can’t use the existing name because… then it wouldn’t be unique. Important: you can only use lowercase characters and numbers. Some symbols also work, but let’s make life easy on ourselves and skip symbols today, aside from dash:

My original:

My edited:

With that set we need to go into AWS Organizations to get the account ID for our SecurityAudit account. Start in the upper right to jump into Organization, then click the arrow to expand your Security OU, and you can then copy the account ID:

Now you have the 3 key pieces of information you need to assume a role from the console (technically you only need 2, but the third will be very helpful for consistency):

• The ID of the account you want to assume the role in. This is our SecurityAudit account ID.

• The name of the role we will assume. That is OrganizationAccountAccessRole, which you should copy and paste. I use it so often I have it set as a keyboard shortcut (macro).

• The name of the account you are assuming the role in. This is not technically required, but as you will see in a moment it shows up in your user interface, and setting it will help you know which account you are operating in without memorizing the account ID. (Pro tip: if I need a ‘name’ but don’t want to make one up, I just set the name to the account ID).

To assume the role and jump into the other account we click in the upper right, select Switch role, skip past the interstitial explainer if necessary, and enter those 3 pieces of information. The information you need to do this from the command line or API is a bit different, because with those you use the ARN of the role, which includes both name and account ID. In that case you also need to set a session name, and we’ll get there once we start playing with command-line stuff — probably in a couple months.

Now you’ll be using your SecurityAudit account. Look in the upper right corner and you’ll notice a different color (I picked green) and the name you specified for the account (remember, you type this in, so you could just type in “root” but it’s just… a tag and you aren’t actually in the root account — you’re in the account whose ID you specified).

Right below that you’ll see the actual role name and account ID. What’s funny is that I have no idea when AWS added that because… I’m old and don’t pay attention. Cool feature!

Now go to S3 in the console to make a new bucket, which we will use in the next couple labs to save all CloudTrail logs for the entire org. (By now you should know how to find S3 in the console)

There are two key settings: specify us-west-2 for the AWS Region, and paste in your new bucket name (with your appended arbitrary characters). Strictly speaking this doesn’t need to be in us-west-2 (Oregon), but I want to keep everyone consistent — S3 only supports 2 regions anyway.

Leave all other settings at their defaults and click Create bucket at the bottom.

You should see something like this:

That’s it for the main lab, but…

Bonus Review

To reinforce the AssumeRole concept, visit IAM, Roles, and click the OrganizationAccountAccessRole. Notice that you see Permissions, which is the permissions policy (AdministrativeAccess) and Trust relationships, which is the trust policy. Take a look at that JSON. The translation here is not “only let the root user from the management account” assume this role, but really “let anything in the management account” assume this role. Yes, it is very confusing the first time you see this, but I saved you the effort, so you should send me chocolate chip cookies.

Finally return to your management account: go into the upper right corner again, and click Switch back.

Lab Key Points

• To assume a role in the console we use the “Switch role” feature.

• Behind the scenes this makes the sts:assumerole API call for us.

• When creating S3 buckets, names need to be globally unique (across the entire Internet); they may contain only lowercase characters, numbers, and some special characters.

-Rich