AWS Certified Solutions Architect — IAM

IAM, abbreviation to Identity & Access Management, is the service used to create new accounts and manage authorization on AWS resources. It is considered a global service inside AWS, which means that changes made inside IAM will be available in all regions at the same time.

To manage what a user can or cannot do we declare a policy. In a policy we must define the following items:

• Actions: the actions that will be considered in this policy. It can vary from a specific action on a specific service to all actions on all services.
• Resources: the resources where the actions defined take effect.
• Effect: what should happen when the criteria of this policy are matched. The available options are Deny/Allow.

Policies

A policy is a document that defines permissions. Policies are written using the Access Policy Language. The policy below is an example that allows full access to all services from all resources:

{
    "Version": "2012–10–17",
    "Statement": [{
        "Effect": "Allow",
         "Action": "*",
         "Resource": "*"
    }]
}

As they are commonly used, AWS made default templates representing job functions in a company. Some useful templates are:

- AdministratorAccess: provides full access to all AWS services and resources
- PowerUserAccess: provides full access to all AWS services and resources, but does not allow management of Users and groups
- ViewOnlyAccess: provides read-only access to all AWS services.

AWS also provides default template policies for all of their services. For instance, if one of the users is only allowed to access EC2 there is a policy called AmazonEC2FullAccess that grants the required permissions.

When a policy is not defined the default behavior is to deny access to the resource. If we create a user with no policy attached he won’t be able to do anything. It is also important to note that an explicit deny will always override an explicit allow. If we have two policies attached to a user, one allowing access to a resource and one denying access to the same resource, the AWS will consider that the user doesn’t have access permission.

Identities

We must represent a person or a service on AWS in order to provide the proper authentication. This representation is made using identities. There are three kinds of identity that can be created: users, groups, and roles.

An IAM user is an entity that allows users to login into the AWS Management Console and make API calls. Each user will have a login and a password to access AWS Management Console, which must follow the password policy defined on IAM. The API calls are made using an access key. Each user can have two access keys at the same time.

An IAM group is a collection of IAM users. They are useful to manage permissions since a policy attached to the group is going to be attached to all users on the group as well. For instance, instead of attaching a policy that allows full access to EC2 for each developer, we can create a group named Developers, attach the policy to the group and add all the developers to this group.

An IAM role is used to define permissions on AWS services. The main difference between a role and a user when accessing an AWS service is that roles don’t have credentials, avoiding them to be exposed. If we want to access AWS resources from EC2 we can use credentials from an IAM user, but they will be stored on the EC2 instance, which is a bad security practice. Instead, we could create a role with the proper policies attached and add it on the EC2 instance. This will grant the right permissions without exposing any credentials.