IAM Users#

When you created your AWS account you started with a root user. It's considered bad practice to use this user on a day to day basis, so we created a new user earlier in this section called iam-admin. That new user has general, all round permissions to manage our IAM resources and its primary objective is to create new IAM users that we use to get work completed.

Let's visual this:

We already have user a root user, and we have not created any "Adminstrator User" (we don't need one, but we are going to create new users soon). Instead what we're interested in is the iam-admin user. Notice how our iam-admin user has permissions to manipulate IAM but nothing else, and our other non-root user has permissions to manage a few other services, but not IAM. And notice how root can do anything? Absolutely anything. That's dangerous. Avoid using the root user as often as you can.

Our iam-admin user is designed for us to login, manage IAM (create new users, reset passwords, etc.) and then logout again.

If the second user in the list has their account hacked, then the attacker can do some pretty nasty things, but what they cannot do (provided you've configured them correctly) is add new users or give themselves a back door into our AWS account (from an IAM perspective.) If they compromise our IAM user, however, then they might be able to get away with that, hence why, like thr root user, the iam-admin user is not a "daily driver".

Generally speaking, this is called compartmentalisation. It means that should our normal user accounts get compromised, the damage that can be done is kept inside of a small "blast radius" and is limited to a subset of our overall estate. Because our normal user will (eventually) have API keys set up, it becomes more vulnerable to attacks and credential leaks. Therefore, that user is not going to be given access to manage IAM. And the opposite is true of our iam-admin user - they haven't beeen given API keys, so there's a reduced risk that their account can be compromised.

User details#

Let's explore our iam-admin user account in a bit more detail.

Start by logging into your AWS account using iam-admin user and explore the user in more details. Goto the IAM console and click on the username in the list and the user's account details will appear.

1. Here's our user name again, so we can see we're looking at the right user/account
2. This is our ARN (with my AWS account number blurred out), which we've talked about previously
3. here we have our permissions, which we can see come from "Attached directly" policies
4. And finally we can see that the policies we've attached are managed by AWS

This is a view you'll see a lot as you manage IAM Users. Just above the list of permissions we can see some tabs: groups, tags, security credentials, and access advisor. Let's explore these options, below.

Groups#

As we've said previously, you can create an IAM Group and use it to "group" IAM Users together. This is handy for when you have a common set of permissions you want to assign to users based on some role or department, such as having a database-admin group.

I don't often see groups being used directly inside of IAM. Generally speaking, most organisations just create users and attach roles to them. They use roles to define their permissions based on their job.

Tags#

You can attach tags to almost anything in AWS, including IAM Users. Tags can help you manage your users and also inventory them. By using tags, you're able to quickly and easily manipulate specific AWS resources using the API. This is due to the fact that you can filter most API calls to target specific resources based on their tags.

This is a powerful concept you'll come to use a lot.

Security Credentials#

This is where the user's API keys are defined. Let's take a look at this tab:

1. here we can see where the "Access Keys" (API keys) are created
2. We're NOT going to create such keys for this user, as they're designed to be locked down

But should you want to create a new Access Key "pair" for this user, it's that button (2) that you would press. You'll be given an access key and a secret key. These are then used to authenticate and access the AWS API from a whole host of other locations, from code, SaaS products, the AWS CLI, and way more.

Access Advisor#

This is a cool feature of IAM. It's essentially an audit log of what this user can access, has accessed, and when. Here's what we have for this brand new user:

1. We can see what this user can access...
2. And we can see when (never) this user has access what they're allowed to access

Honestly, I've never been asked to use this feature because there are other much better ways of handling this. We won't go into that in this course because we're trying to stay focused on the important stuff here.