IAM allows you to give out managed access of your AWS resources to your employees, AWS services, and programs running on remote servers. IAM groups is a useful organization tool that allows you to define permissions for multiple users at once.
IAM’s Organizational Tools
First off, a quick breakdown of IAM’s different tools:
IAM Policies group together individual permissions to form a cohesive object that can be applied to users, roles, and groups. For example, you might create a policy that allows access to put objects into a specific set of S3 buckets.
IAM Users have access keys or passwords that allow them to access AWS services from the CLI, API, or Management Console. This allows employees to be able to access AWS resources from outside your AWS account. They can have policies attached to their account, which give them permissions.
IAM Roles are similar to users but don’t come with any access keys. These are used to give other AWS services permission to use your resources, and don’t give API or CLI access to anyone outside of your account. For example, you can give an EC2 instance a role that allows it to access S3, and because it’s running in your AWS account already, it can act as the role without requiring access keys.
AWS Organizations is a special tool that allows you to split your root AWS account into up to four different sub-accounts with centralized billing and control. While technically unrelated to IAM, this allows you to completely separate development, testing, staging, and production environments, which can allow you to give more lax IAM permissions to employees working only in the dev environment.
IAM groups is what we’ll be discussing today. This tool allows you to attach multiple policies to a group, and add users to that group, which will be given the same policies that the group has. It’s a great organizational tool and crucial for keeping track of multiple users.
How to Work with Groups
Groups allow you to distinguish different classes of employees with different permissions. For example, say you have a team of software developers and a team of QA engineers. Both have different requirements, and as such, need different permissions. Setting them on the group allows you to easily set up new employees with access, or move users between teams when the need arises.
Create a new group from the “Groups” tab of the IAM Management Console.
Give it a name, and attach any policies you’d like. Groups can have a maximum of 10 policies attached, so you’ll likely want to make a custom policy or two for this group to have. You can also add inline policies directly to the group, but we advise using a regular policy to keep everything orderly.
Click “Create,” and that’s all the setup that is required. You can add a new user to the group from the group’s “Users” tab:
Or, if you’re automating your onboarding process, you can do it from the command line with:
This will add the group’s permissions to the user’s current permissions in a separate category. If you remove the user from the group, the group’s permissions no longer apply.
You can’t create subgroups, but users can be included in multiple groups at once. With this in mind, you could create a “Developers” group that assigns basic permissions, and a “Senior Developers” group that gives more permissions, then assign them both to an employee to give them both sets of permissions.
Groups Don’t Override Permissions
In IAM, there’s no way for a permission to “override” another permission. By default, everything is implicitly denied, and a user will only have access to services that are explicitly allowed by a permissions policy. You can also choose to explicitly deny permissions to a user. These permissions will always take precedence over any other permission, regardless of whether or not it comes from a user or group.
When you create a group, all of the groups’ permissions interact with the user permissions in the same way that they would if they were attached directly to the user. There is no hierarchy.
For example, we’ll create a test user and attach the AWSDenyAll policy directly to it. We’ll also create a group, attach the AdministratorAccess permission to that group, and add the user to that group.
From the IAM Policy Simulator, everything comes up as explicitly denied due to the presence of the AWSDenyAll policy. If we switch things around, and put the Deny policy on the group and the Allow policy directly on the user, the same thing happens. Deny will always override Allow.
A more useful form of this is permissions boundaries. Rather than explicitly denying everything you don’t want a user to be able to do even if the group says they can, you can instead set a policy as a permissions boundary. This will take precedence over all other permissions attached to the user, both from groups and directly, and not allow anything that the permissions boundary doesn’t also allow.
This essentially works like a Venn diagram of permissions, and only allows actions that overlap both the explicitly allowed permissions of the attached policies and the permissions boundary.
