Prerequisites

• Completed setup of IAM Identity Center

• Have the following accounts in your organization:

  • SecurityAudit

  • LogArchive

  • IAM

  • SecurityOperations

The Lesson

Back when we set up IAM Identity Center we created a new user for… us (or rmogull, for all of you who take my instructions way too literally) and gave ourselves full administrative access.

As a quick reminder, Identity Center starts with users. A user can be put in a group. We also create permission sets. A set is a collection of user-based policies — basically a group of policies. So, for example, one permission set could have the IAM policies for AccessAnalyzerServiceRolePolicy, AmazonAppFlowFullAccess, and AmazonAppStreamPCAAccess, and the user would get all those permissions. Why those 3 policies? Because they are all on the first page of the AWS managed policies for me to randomly pick, instead of coming up with something realistic.

To enable access you assign a user or group a permission set at the level of one or more accounts. Identity Center then creates an IAM role in the account, and attaches the selected IAM policies. For now we will limit discussion to built-in AWS managed policies; you can also write your own, but AWS has to handle those a bit differently. AWS managed policies exist in every AWS account. Customer managed policies only exist in the account where they are created, so AWS needs to provision those policies into accounts for it all to work.

Thus you log into Identity Center, see a list of accounts, click an account to see the assigned roles, and then click to assume that role into the account.

If you got a bit lost here, you can review the lessons where we covered roles and policies:

• Create Your First IAM Role

• Write a Simple IAM Policy

• Assume the Role

Core Security Team Roles

With that out of the way, let’s talk about your security team. I mean, you are the security team, but we’ll pretend you work for a big company with a team. Because make believe is fun, and I doubt Disney will create “The Hall of Cybersecurity Heroes” (sorry Chris!) we’ll just do it ourselves.

Well, this lesson is actually valuable even in our little lab accounts. One of the great things about AWS is that we can switch personas (roles) for sessions, and work with just the permissions we need at that time. I’m going to start getting you in the habit of using different personas, which reduces the risks of using full admin all the time.

Today we will expand our admin access and set up 2 new permission sets (roles), and assign ourselves access to certain accounts. I’ll explain the roles and why I recommend them first. We will get into the actual names and account mappings in the Lab section:

• A full-read role with a read-only policy. Security should always have full read capabilities (and yes, this is sometimes controversial). This role can be used by incident responders. Why is it controversial? Because it lets those users see data, including sensitive data. My opinion is that responders need the ability to see what they are working with in an incident. In our labs we will just be able to use this role, but way in the future we will talk about how to make this a Just In Time permission (JIT) that can only be used if someone else signs off on the request.

• A full admin role that can do anything. We already have this, but we will assign it to more accounts. I recommend having this available to incident responders in case they need to “break glass” and jump into an account under active attack. Believe it or not, a lot of places don’t support responder access like this, and require them to work with an app or cloud team for making changes when containing and responding to an attack. That’s fine if the app or cloud team is available 24/7 and knows how to contain an abused IAM session without breaking application functionality. JIT access is the way to handle such power. But for our labs we are the admins and the security team, so we’ll just worry about that later.

• An IAM role for managing … you guessed it… IAM. Someone needs to create all those juicy roles and entitlements. This should be a security function.

• There is an additional cross-account role we will get to later which is tuned for incident response. Why a cross-account role instead of an Identity Center role? Partially for control, and largely because we’ll use that one with tools that are, in some cases, pre-configured on established systems. Why not build that now? Because it’s a different process, and would bust our 15-30 minute per-lab limit.

You can get crazy with all sorts of additional slicing and dicing of permissions, but this set will work well for our labs and it’s what I like to use, albeit requiring JIT permissions for at least the full admin role. In a really large org you probably need more roles for things like security engineering, where they need to manage some services but don’t need full admin.

But we’ll balance simplicity for our labs with enough granularity to make the point: a read role for keeping an eye on things, an IAM role for managing users and permissions, and a full admin role for those bad days when you need to dive in and start changing things at 3am, for when North Korea decides to treat your account like the mines of Moria.

Lesson Key Points

• Security teams need different roles for different tasks. The main ones I like are:

  • Full read for those bad days when you need to hunt the bad guys/girls/rogue AI.

  • IAM manger for managing IAM.

  • Full admin for security responders, on the really bad days when the AIs try to take over and turn you into a living battery trapped in a digital hallucination.

The Lab

The Lesson section covered what we’ll do today. It will be a 4-step process:

1. Create the permission set for the read role.

2. Create the permission set for the IAM role.

3. Create groups for the security team and the IAM team.

4. Assign the groups to the proper accounts.

Some of this lab is repetitions as we cycle through things. There won’t be a screenshot for every cycle when we repeat a step, but you can always refer to the video if you get lost.

This lab looks really long but I timed it out, and even with mistakes it only took 9 minutes.

Video Walkthrough

Step-by-Step

Start by signing into your Identity Center portal and go to CloudSLAW > AdministratorAccess. Even though we set up delegated administration, we never gave ourselves access to the IAM account to use it.

Go to IAM Identity Center, then AWS accounts. The first thing we will do is add ourselves to all our existing accounts, then we’ll go into the delegated administrator account (IAM) to set up all the other permissions.

Expand out the Security OU and the Workload OU > Prod OU. Then check the boxes for the following accounts and double-check that it looks like the screenshot below:

• IAM

• SecurityAudit

• SecurityOperations

• TestAccount1

(Remember you already have access to LogArchive).

Then scroll to the top, and on the side click Assign users or groups:

You only have one group, so pick Administrators and then Next:

And hey, we only have one permission set! If you mess this one up, it ain’t my fault:

Click Submit, then wait for the little script to finish:

Close out that browser tab and refresh the tab with your Sign In portal. It should now look like this:

Let’s dive into our IAM account:

This is the cool part. We are managing Identity Center from the IAM account, even though it’s running in our Management Account! Alright, enough celebrating — go to Groups and Create group:

Name it Security Administrators, add your username, and then Create group:

Repeat those steps for an IAM Administrator group with the description Can administer Identity Center. When done it should look like this:

Now go to Permission sets and Create permission set:

Choose the Predefined permission set, then scroll down and select ReadOnlyAccess, then click Next:

This is a good time to mention that ReadOnly provides pretty deep permissions, and will enable you to see data in many services — not just metadata. ViewOnlyAccess and SecurityAudit are basically the same thing, letting you see a lot of metadata, but not the actual data. I tend to find SecurityAudit rarely meets my needs. You can and should read more from Chris in this great post.

We will leave the defaults, but I want to mention two things. The first is that you can adjust the default session duration. For developers/etc. you may want to set that to something longer like 4-8 hours (I don’t like 24). They will need to refresh their sessions after that. For security stuff keep it to an hour. There’s also a cool feature to drop you into part of the AWS console after you log in: the relay state. We won’t use that today but I encourage you to play with it. For example, you could drop the IAM administrator right into Identity Center. Why aren’t we using that? Because I was pressed for time and too lazy to figure out the right pattern. If you figure it out feel free to email me and I’ll send it out in the next monthly post.

Looking good? Create:

Now we need to go through the process again, this time for our IAM administrators, but we won’t be using one of the predefined roles. Create permission set and then choose Custom permission set and Next:

The next screen will show 4 options: AWS managed policies, Customer managed policies, Inline policies, and Permission boundaries. We will still use an AWS managed policy, but you may recall that you could write your own Customer managed policy. You could also insert a one-off inline policy. I promise, we will get to all these over time.

In the Select policies box type in SSO, which is the old name for IAM Identity Center. Considering how much my fingers hurt writing this post, guess my preference? Then select AWSSSOMemberAccountAdministrator. This will let us perform all the IAM functions we need from a delegated administrator account. Then click Next:

Name it IdentityCenterAdministration with description Administer AWS IAM Identity Center from a delegated administration account and click Next, and on the next page click Create:

You will now have 3 permission sets:

Let’s assign these. Go to AWS Accounts and click Security > IAM in the tree, then in the upper right click Assign users or groups:

Choose Groups then IAM Administrators, then Next: 

Choose Identity Center Administration and click Next:

On the final page click Submit and wait again for that little script at the bottom of the page to run. As a reminder, this is just a wizard in the front-end UX that’s making the sequence of API calls needed to push the role down into the account.

Now let’s assign our Security Administrators group ReadOnly access to all the security accounts. That way we don’t always need to go in with full admin. We’ve done this a few times now, so I will just show a few screenshots; you should be able to get through it without more help:

All set? Good, because we now have one last permission set to create and assign. This time I’ll skip all the screenshots — we have done this 4 times already.

• Create a Permission Set.

• Assign it the AdministratorAccess policy.

• Call it SecurityFullAdmin.

• Then go to AWS Accounts.

• Assign the Security Administrators group SecurityFullAdmin to the following accounts:

  • LogArchive

  • SecurityAudit

  • SecurityOperations

To review we, as administrators of everything, have full admin to every account. But we don’t always want or need all that power, so we also added ourselves to the Security Administrators group and assigned ourselves read access. This lets us poke around with lower privileges. We also added admin to the Security Administrators group since we may hire some people someday, and they’ll need those permissions, but they only have it for the security accounts.

All that said, we are still missing something I mentioned. We want the security team to have read access to workload accounts. So for our last step…

• Assign Security Administrators the ReadOnlyAccess permission set to the TestWorkload1 account:

Phew. All set. So what does all this look like now? If you refresh your portal page you will see that you can now drop into different accounts with different permission levels.

While it seems complicated, remember that your average AWS users won’t need so many different or complex permission levels. Since you are the only user in the system right now, we assigned them all to you so you could see how it works.

Lab Key Points

• One method of implementing least privilege is to assign different personas, each with different entitlements, so a user can pick just the permissions they need for a session.

-Rich