Prerequisites

• Have completed Bring in the Fed(eration)

The Lesson

It’s finally time for a nuts and bolts lab. I don’t have a lot of general theory to discuss — we’ll quickly jump into implementation. In our last lab we enabled IAM Identity Center, created our user account, and set up our MFA. On the way we learned about federation as a Single Sign On strategy, and a bit on how it works. We covered Identity Providers (IdP), Relying Parties, the trust relationship, and assertion.

TL;DR: You log into an IdP which gives you access to a relying party, who still gets to decide what you are allowed to see and do. All this uses fancy crypto and digital certificates.

This week we will cover the primitives of IAM Identity Center and how we can map from our user to getting access to multiple AWS accounts.

Here’s how the basics work:

• IAM Identity Center can work either as an IdP; or it can be a relying party which works with an external IdP such as Okta, Microsoft, of JumpCloud.

  • We are setting things up with IAM Identity Center as the IdP, which means that’s where our user accounts live.

• Groups are collections of users. We can assign permissions based on both users and groups, but use groups as much as possible.

  • We created an Administrators group last week, but didn’t give it any permissions.

• Permissions are granted using something called a Permission Set. A permission set is a collection of up to 10 IAM policies. These are the exact same policies we’ve been using since the start. Think of a permission set as a box full of policies.

• To provide access to an account, you assign a user/group a permission set and accounts. It’s a 3 part equation: group + permission set + account = what you can do.

• Users and groups can be assigned multiple permission sets per account. When they go to access that account, they just pick whichever permission set to use from the list of ones they were granted. If you think back, this is the persona we discussed. So I can go in with full admin, power user, or read-only access — depending on what I need at that point in time.

• Behind the Scenes

  • When you enable Identity Center for an account, AWS Organizations adds Identity Center as an identity provider for that account (we’ll look at this at the end of the lab). It handles all the complexities of linking up an IdP for you.

  • When you assign a permission set, that creates an IAM role in the account with the IAM policies you defined. It then sets the role trust policy to allow the identity provider (IAM Identity Center) to assume the role.

    • These are special roles that you can’t change or delete within the account. I mean, probably? I haven’t tried to break it this way yet, which is really unlike me.

  • When you log into Identity Center you see a list of accounts. When you click the account you see a list of roles you have access to. Then you click one, and the console performs a “switch role” operation for you (remember, the console calls it “switch role” but the API call is “AssumeRole” — in this case AssumeRolewithSAML).

    • This creates a session. It also adds your identity (username or email) to the session name, which is awesome for tracking.

Here’s my usual pretty picture, then let’s get to work…

Lesson Key Points

• IAM Identity Center can work as an Identity Provider, or as a bridge into AWS from external identity providers.

• A permission set is a collection of IAM policies.

• To assign access we map a user/group to a permission set to an account.

• This creates an IAM role in that account, which the user can assume.

The Lab

All the setup is in the Lesson section this week. We will assign our group to a permission set, and our 2 accounts with administrator access. Then we’ll log in and test it. Finally I’ll embed some screenshots of what this looks like in IAM and CloudTrail logs. I won’t do the full step-by-step for that, but if you are interested it should be easy to replicate.

Video Walkthrough

Step-by-Step

First, go to https://console.aws.amazon.com and sign in with your regular admin user, still. Starting with the next lab we’ll stop using that and use the new Identity Center user instead, but we haven’t given it permissions yet. Then go to IAM Identity Center and click Permission sets.

The Create permission set.

We will go with a Predefined permission set and AdministratorAccess. This is just a shortcut to adding the IAM policies — you could also manually add your policies.

Then click Next.

Name it AdministratorAccess, with description Full admin. There are two other settings we won’t change, but which are good to know. The session duration is probably obvious, and I like to keep it at an hour. However for developer access you might want to extend that to 8 hours or more. It’s a slight security risk increase, but may keep them from hating you.

The second is the Relay state, which is just a fancy way of saying “when the user logs in with this permission set, put them into this part of the console”. If you have someone in accounting just logging in to check out the bills, this would make their life easier.

Then Create.

Now let’s assign access to our accounts. Click AWS Accounts and then swap into List mode. You could do this part in Hierarchy view, but I want you to see both.

Then select all the accounts (okay, both). Then Assign users or groups.

Then work through the wizard, and pick the group and the permission set. This should be easy — we only have 1 of each.

Don’t go anywhere yet! The wizard needs to run the API calls in the background and provision the IAM role for each account (yes, this can take longer in larger environments). Once AWS says it’s safe, it is (relatively).

Now it’s all set up. You have your “new” rmogull admin user created and assigned to the administrators group, and assigned the AdministratorAccess permission set to both your existing accounts.

Phase 2: Test and Explore

Now we’ll log in and drop into an account. Then I’ll show a few screenshots to reinforce how this works — feel free to follow along and explore in your own accounts.

First, while still in Identity Center, click Dashboard and grab the URL for your sign-in portal (in case you didn’t keep it from last week).

From now on THIS is where you will go to log into AWS for most of the rest of our labs. The only time we’ll use the regular console again is when we need to use the root account for something, if something breaks, or if I come up with some idea I haven’t thought of yet.

Once this next login works, you can stash the admin account we’ve been using until now in a drawer until I tell you to use it, or you move and realize you left it in there with a half-eaten Snickers bar you forgot about, which has achieved sentience and mastered ChatGPT.

First we need to log out. Click in the upper right corner and Sign out. Then open a new browser window and paste in your access portal URL. Enter your username, password, and MFA. Notice that this looks different than the main AWS console login — we are using an entirely different service.

This takes you to the dashboard with a card for AWS. Why not just list your accounts? Because although we skipped it, Identity Center is a full IdP, and you could use it as a portal to other applications — including Salesforce, ServiceNow, Box, and probably Billy-Bob’s Bait Shop and Secure Code Repository. Click the card and you’ll see the 2 accounts we provisioned. Then select SecurityAudit to show the roles you can access. In this case it’s just AdministratorAccess — and since I haven’t yet shown how to play with the CLI or APIs, click Management console. A cool thing about these AssumeRole operations is that if you did pick Command line, you would only get temporary credentials which expire in an hour (our current session time).

You are now in the console as your SSO user. If you look in the upper right corner you’ll see the role and your username.

Okay, the lab is done unless you want to explore!

There are a couple interesting things to see. The first is to look at the role that SSO created and the associated IAM policies. Go to IAM > Roles, and you’ll see a new “Reserved” role:

Notice the name has a prefix of AWSReservedSSO, which should be pretty clear. Then the name of the role (we picked one of the pre-built packages), and then some random characters. You’ll see this a lot in places where you don’t explicitly set the name. This is how AWS helps avoid naming conflicts and, to a lesser degree, name reuse. Click the role and then look at the Trust relationship:

There are 4 elements to highlight:

1. This is the ARN of the Identity provider which Identity Center/Organizations created in the account. You can see it if you look under Identity providers. An AWS Organization can have more than one of these, but you really don’t want to go down that road unless you need to, so we’ll use SCPs to block it later.

2. This gives the role permission to use the AssumeRolewithSAML API call, which is a bit different than AssumeRole but very similar. You can look that up on your own time if you are really curious. Like when we set up to Switch roles, this permission needs to be in place in the Trust policy for the Principal which is allowed to use the role.

3. This lets the IdP tag the session when you assume the role. This is very valuable for tracking, because it adds a session name which aligns with the user assuming the role.

4. The last is a condition that only allows this when using the signing portal, and only the AWS one. You can’t assume this role from any other origin.

Final Bonus

Follow these steps to replicate, or just look at my screenshot. I will to make a change while logged in as this SSO user, and show you what it looks like in the logs:

• I went to IAM and created a group named delete. I did not give it any permissions, so it’s just an empty group which can’t do anything — so means there is no risk in case I forget about it.

• Then I went into CloudTrail and picked us-east-1/Virginia for my region, since that’s where all the IAM API calls are recorded.

• Look in Event history to see the API call and how the identity block is structured:

Notice how easy it is to see the role and user in the ARN? Things aren’t always this perfect — take my incident response class to find out why — but it’s darn nice when they line up.

That’s all for this one!

-Rich