AWS IAM: Understanding the Key Concepts of IAM services

What is IAM?

AWS Identity and Access Management (IAM), as its name suggests, is the AWS service that deals with identity and authorization.

Whenever you try to achieve any action on AWS, you have to go through IAM which will identify you and then allow or deny the action depending on the rights that have been granted to you by your account administrator.

If you use AWS, you use IAM, whether you’re aware of it or not.

For example, when you connect to the AWS web console, it is IAM that checks your login and password and allow you to access your account. Then, when you try to create a new EC2 instance, it is still IAM that checks that the rights needed to carry this action have been granted to you by your account administrator.

The same goes for an application trying to access a resource hosted on AWS: IAM will identity the application thanks to the access key provided and will check that the action is indeed authorized.

Accounts and Users

Accounts

An account can be seen as an environment owned by an organization, a team or an individual.

The words 'account' and 'user' can often be used as synonyms in a conversation. Let's not make that mistake when talking about AWS since those two words mean two different things. If you tend to mistake your username for your account ID, remember that the latter is a 12 digits number whereas a username could be any character string.

It is common for an organization to possess a number of AWS accounts, in order to separate each different environment. One account could host the development environment, another could host the staging environment and the last one could host the production environment.

Users

A user is an AWS entity associated with an individual or with an application. A user has identification information in the form of a username and password pair or an access key. It is possible to organize users in groups in order to facilitate authorization management.

When created, an account is populated with a single user: the root. This user should create other users as its organization grows. It is crucial to understand that this root account should not be used for day-to-day operations. Use it to create users and give those users the permissions they need.

There is also another concept that could easily be compared with a user: the role. We will see what the role is all about in the third part of this article so we can introduce a few more concepts that we will need to understand it more easily.

Requests and Policies

Requests

• Principal: User or role who requested permission.
• Action: Operation that the principal requests to make on the resource. The name of these actions is composed of the three letters’ name of a service and the name of the action beginning by a verb.
  

"Action" : "ec2:StartInstances"

"Action" : "iam:ChangePassword"

• Resource: Target of the action.

E.g.

NB: You may have noticed that the formats of those identifiers are not exactly the same:

• The region is specified for the SQS resource but not for the IAM resource. This is because the IAM service is trans-region and the SQS service is not.
• The resource type is specified for the IAM resource but not for the SQS resource. There are a few types of resources in the IAM service (users, groups, roles, policies...) whereas there are only queues in SQS.

Keep in mind that ARNs (Amazon Resource Names) are created to identify a resource in a unique way while being as short as possible.

Policies

A policy is a rule controlling a user, a group or a role access to a resource.

Standards policies are directly available but it possible to create other policies to answer a specific need.

Similarly to the request, the policy defines the Action and Resource fields and add an Effect field that indicated whether the action should be allowed or denied.

E.g.

Here is an example of a policy in JSON format.

This policy allows any EC2 action. It is also possible to encounter policies specifying a Principal field instead of a Resource field when talking about a trusted relationship

E.g.

This example allows Amazon Directory Service to assign this role to its users. It would also be possible to allow users from another AWS account to use this role with a similar trust relationship. We will see an example of those in the third part of this article.

A policy is in effect only when it is attached to an IAM entity (user, group or role). When a policy specifying a Resource is attached to a user, this user is the Principal of the action. On the contrary, if the policy specifies a Principal, it should be understood that the entity it is attached to is the Resource.

Figure 2: Diagram illustrating the use of strategies

On the diagram above:

• Bob can make any RDS action on any resource
• Alice can make the rds:DescribeDBInstances on any resource. However, she tries to make another action (rds:StartDBInstance). Therefore her request is rejected.
• Anne can make any RDS action on the resource identified by its ARN.
• Mehdi can make any RDS action on any resource but one specific resource identified by its ARN. He still tries to act on this resource. His request is rejected.

Important: When both a policy allowing access and another denying it can be applied to the same resource, the access is denied.

Roles

A role is an AWS entity that can be compared to a user. However, a role is usually not associated with an individual or a precise application. Many users are usually given the right to assume a role (i.e. use temporarily the rights associated with a role). A role, contrarily to a user does not have a password and uses temporary identification information.

Generic roles are already created on IAM and are directly available but it is possible to create new ones to deal with a precise need. Those generic roles are already associated with generic policies.

A role could be used to allow users from a different account to act on resources on the role’s account.

It is this practical case that we will try to illustrate with the following two diagrams.

First, let's detail the result of the different requests executed directly from the user to the resource without using a role:

Figure 3: Diagram showing direct access to a resource from another account

• Bob and Alice try to act directly on a resource hosted on an account different from theirs; Their requests are rejected.
• Bob can make any RDS action on any resource and is in the same account as the resource he tries to act upon.

Important: It is necessary to assume a role to act on a resource on a different account.

Now let's see what happens when users use the role to access the resource:

Figure 4: Diagram showing access to a resource from another account through a role

• Bob and Anne do not have a policy that allows them to male the action sts:AssumeRole. Their requests are rejected.
• Alice can make the sts:AssumeRole on a specific role identified by its ARN. Her request is allowed and she can then use the role to make the action rds:StartDBInstance.

IAM is a crucial part of AWS and, as a user, you will be confronted with it whether you want it or not.

It is generally not part of AWS that people like to spend their time on. It is often seen as the bad cop that doesn’t let you live fully your experience in the virtually unlimited word that is the cloud.

However, spending some time to understand the mechanics behind the curtain of IAM helps you avoid moments of profound desperation in front of a “403: FORBIDDEN” message on your console.

So my advice to you is to get comfortable with the basic concepts explained here; your future self will thank you.