IAM allows you to provide managed access of your AWS resources to your employees, AWS services, and applications running on remote servers. IAM Groups is a useful organizational tool that lets you define permissions for multiple users at once.
IAM’s organizational tool
First and foremost, a quick breakdown of IAM̵7;s various tools:
IAM policies group individual permissions to form a coherent object that can be applied to users, roles, and groups. For example, you can create a policy that allows access to place items in 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 access AWS resources outside of your AWS account. They may have policies linked to their account, which gives them authority.
IAM roles are similar to users but have no access keys. These are used to authorize other AWS services to use your resources and do not provide API or CLI access to anyone outside your account. For example, you can give an EC2 instance a role that allows it to access S3, and since it is already running in your AWS account, it can act as the role without the need for access keys.
AWS Organizations is a special tool that allows you to divide your root AWS account into up to four different sub-accounts with centralized billing and control. Although not technically related to IAM, you can completely separate development, testing, staging, and production environments, allowing you to provide more relaxed IAM privileges to employees who only work in the development environment.
IAM groups are what we will be discussing today. This tool allows you to link multiple policies to a group and add users to that group, who have the same policies as the group. It is a good organizational tool and crucial for keeping track of multiple users.
How to work with groups
With groups, you can distinguish different classes of employees with different permissions. For example, suppose you have a team of software developers and a team of QA engineers. Both have different requirements and therefore need different qualifications. By setting them up in the group, you can 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 the policies you want. Groups can have a maximum of 10 policies attached, so you’ll probably make a custom policy or two for this group. You can also add integrated policies directly to the group, but we recommend that you use a regular policy to keep everything organized.
Click “Create” and all installation is required. You can add a new user to the group from the “Users” tab:
Or if you automate your boarding process, you can do so from the command line with:
aws iam add-user-to-group --group-name
This adds 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 cannot create subgroups, but users can be included in multiple groups at once. With this in mind, you can create a “developer group” that assigns basic permissions and a “senior developer” group that gives more permissions and then assign them both to an employee to give them both sets of permissions.
Groups do not override permissions
In IAM, there is no way for permission to “override” another condition. By default, everything is implicitly denied and a user only has access to services that are explicitly allowed by an authorization policy. You can also choose to expressly deny permissions to a user. These permissions always take precedence over all other permissions, whether they come from a user or group or not.
When you create a group, all the groups’ permissions interact with the user permissions in the same way as they would if they were linked directly to the user. There is no hierarchy.
For example, we create a test user and attach
AWSDenyAll directly to it. We also create a group, attach
AdministratorAccess permission to that group and add the user to that group.
From IAM Policy Simulator, everything comes out that is explicitly denied due to the presence of
AWSDenyAll policy. If we change things and add the Deny policy to the group and the Allow policy directly to the user, the same thing happens. Denying will always override Allow.
A more useful form of this is authorization limits. Instead of explicitly denying everything you do not want a user to be able to do even if the group says they can, you can instead set a policy as a permission limit. This will take precedence over all other permissions associated with the user, both from groups and directly, and will not allow anything that the permissions limit does not allow.
This works in principle as a Venn diagram of permissions and only allows measures that overlap both the explicitly permitted permissions for the attached principles and the permissions limit.