Overview of AWS IAM

We can see that IAM is a global service, as indicated by the red box. If we go to other services like EC2 or Lambda, we’ll see our region name displayed here instead of the word “Global.”

IAM entities

As we’ll see in this lesson, IAM implements security in AWS accounts by utilizing entities like users, groups, roles, and policies.

Users

An IAM user is an identity that we can use in our organization to access our AWS account. Each user will have their credentials associated with the account.

We also need to attach policies (permissions) to IAM users to allow them specific access to our AWS account. This allows us to control what kind of access a user has. For example, we might want to give high-privilege access to senior developers and limited access to junior developers.

We’ve already used IAM; when we created an AWS account, AWS created a root user for us.

Note: You should only use the root user to set up your AWS account. After that, you or any other person who needs to access the account should do it via their own IAM user. As we’ll see in this course, AWS has some features that can only be controlled by the root user.

Groups

An IAM group is a collection of IAM users. We can use IAM groups to collectively assign policies (permissions) to a group of users.

Let’s clarify this with an example.

We can see two IAM groups with nine users each. All nine users in the Administrators group will have the policies (permissions) attached to the Administrators group. Similarly, all developers will have the policies attached to the Developers group. We can assign the same user to more than one group.

There are ten users in the Senior Developers IAM group. Two are exclusive to this group, while four are concurrently in the Administrators group, and another four are in the Developers group. Users belonging to multiple groups have permissions from each group they’re associated with.

Instead of having to apply policies for each user, using IAM groups allows us to apply policies to a group of users collectively.

Note: In IAM, when a user belongs to multiple groups, they inherit permissions from all the groups they are a part of. However, AWS follows a deny overrides principle. If any IAM group that the user is a part of explicitly denies permission, that denial takes precedence. Therefore, if some users are members of both the Administrators and the Senior Developers groups, and if the Senior Developers group has a policy that denies access to a specific AWS service, that denial will override permission from the Administrators group for those users.

Roles

IAM roles are entities assumed by trusted identity providers or AWS services. Just like IAM users and groups, an IAM role has policies attached to it. These roles are then attached to an AWS service to allow that service to perform specific actions.

For example, if we need an EC2 instance to read messages in an SQS, we need to attach the SQS read policy to the role of this EC2 instance.

Every role in AWS has something called a trust policy. The trust policy defines which service or entity can assume this role. For example, if a role has the following trust policy, it can only be used with the AWS EC2 service (i.e., it can only be attached to EC2 instances).

Note: IAM users are for people.
IAM roles are for AWS services and identity providers. We can’t associate an IAM role with a user or a group.

Policies

An IAM policy is a set of permissions used to control access to AWS services. Policies are stored in AWS as JSON documents. We’ve discussed policies that can be applied to users, groups, and roles. Let’s have a look at an IAM policy.

The version specified in line 2 ("Version": "2012-10-17") is simply the current version of the policy language. We don’t need to remember it. However, we should note that the policy has two statements, one from lines 4–11 and one from lines 12–18.

• The first statement, (“Effect”: “Allow”), allows us to perform s3:Get* and s3:List* operations on all resources (“Resource”: “*”).

• The second statement, (“Effect”: “Deny”), denies us permission to perform any EC2 operation (ec2:*) on any resource (“Resource”: “*”).

So if we attach this policy to a user, they will be able to perform a list and get operations on all S3 buckets but won’t be able to perform any actions in the EC2 console.

In AWS, we should apply the least privilege principle (i.e., don’t give permissions to a user that they don’t need).

Note: If an explicit permission is denied, the policy’s final decision for that permission is always denied, even if you allow that permission in another statement.

In our example, we see that all EC2 actions are denied. Let’s say we have a user with this policy, and we attach the following policy to this user:

One of the policies has an explicit denial for the ec2:* action, and therefore, the second policy won’t work. The policy will result in a denial for all EC2 actions.