IAM Groups#

I'm not going to cover IAM Groups in too much detail because, frankly: they're hardly used in my experience. But we'll most certainly learn enough to use them.

A group is used to literally "group" IAM Users. An group cannot group other groups. It can only contain users. But, you can have as many groups as you like; you can have as many users inside of a group as you like; and a user can belong to as many groups as you like. So they're very flexible and powerful.

But they're not used very much. In most setups, people tend to login to AWS and then assume an IAM Role, which contains the permissions they need, and then they logout again.

Creating a group#

Let's create a group that'll we delete later on.

Whilst being logged into your new iam-admin user, the one we created previously, goto the IAM service and select "User groups". Here's a screenshot:

1. This is where we access the group management section of IAM
2. And this is what we click to create a new group

The next page gives us everuything we need to create a new group and add users to it at the same time. But it also allows us to attach policies to the group, which is where the power of groups comes into play.

Let's click the button and checkout the UI:

1. The group obviously requires a name. This is usually something that alignd with the responsibilities of the users inside the group.
2. We can add existing users to the group here in the UI, at the time of creating the group.
3. And we can attach policies to the group, also. Note how this is also optional.

Let's call our group s3-readers (step 1), add our iam-admin user (step 2), and attach the AmazonS3ReadOnlyAccess (managed) policy (step 3). Here's what this looks like:

1. The name supplied as s3-readers
2. Our user, iam-admin, being added to the group at the time of creation
3. Note that I searched for AmazonS3ReadOnlyAccess and hit Enter, which filtered the list
4. And then you need to select this managed policy by clicking the checkbox

Then hit "Create group".

1. We can see the UI is telling use we've created the group successfully
2. This is the name we gave the group
3. We have just one user in there right now: iam-admin
4. We've defined some permissions and attached them to the group (AmazonS3ReadOnlyAccess)
5. And we created the group just now

Let's now click on the group name in the list and view the ARN and other details, just like we've done for the IAM User we created in the last section:

1. The group's name, as you might have suspected
2. When it was created, but in much more detail (note how it's down to the minute)
3. The ARN of the group for use in API calls, amongs other things
4. The various tabs to other parts of the group's configuration, including permissions and the access advisor
5. Our iam-admin user has been added to the group
6. And note how we can see the activity and creation time of the user from this view too

The "Permissions" and "Access Advisor" tabs should be known to you at this point in time, but in short:

• The "Permissions" tab allows you to manage the policies attached to the group, by adding new ones, removing existing ones, and defining your own inline policies too
• And the "Access Advisor" tab is used to view audit logs for this group, which details what the group's permissions permit and who's done what (and when) via this group's permissions

You've seen most of this before when working with the IAM User interface.

You might also have noticed that an IAM Group's interface doesn't have a "Security Credentials" tab like IAM Users do. That's because an IAM Group cannot create and "own" API keys or other credentials. You cannot login to AWS using a group, only a user (via a username/password combination or set of access keys.)

Deleting a group#

Because we don't need this group, let's delete it! This is obvious: click the "Delete" button in the top right of the group's summary page:

And then you simply confirm by typing the group's name into the confirmation dialogue:

Simple as that.

We'll explore groups later on when we look at policies and roles. As I said, however, they're not used much in a big organisation, who use SSO via security protocols such as SAML.