IAM - Identity Access Management

What is IAM?

IAM is used for managing users and their level of access to the AWS console. It allows you to

• Create users and grand permissions to those users
• Create groups and roles
• Control access to different AWS resources

AWS lets you create a root account. This account has full administrative access to AWS which implies it is important to secure this account. Failure to do so may mean loosing access to the entire account with all it’s computing resources, data and users. You typically should avoid using this account for anything except creating the very first IAM user. The root account is the email you used to sign up to AWS.

Make sure you do these four steps in order to secure the root account.

• Enable multi-factor authentication on the root account
• Create an admin group for your administrators and assign the appripriate permissions to this group
• Create user accounts for your administrators
• Add users to the admin group

IAM is universal. This means that it does not apply to different regions.

Controlling permissions using IAM

Permissions in IAM is controlled using policy documents. These are JSON-documents which describes what given user is allowed to do on a given resource. One example can look like this.

1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Effect": "Allow",
6            "Action": "*",
7            "Resource": "*"
8        }
9    ]
10}

This policy gives an user full access to any resources. IAM policy documents are assigned to groups, users, and roles. Typically users are not given policies directly as they may become hard to manage. Rather it is common to add the policy to a group and then add the user to the group.

AWS provides a ton of different policies for different tasks. So usually you dont need to create these policies yourself.

Users and access

Add users to your AWS cloud instance

Creating groups and attaching policies and users to that group

There are three different types of building blocks of IAM.

• Users - A physical person
• Groups - Functions such as administrators, developers, etc. Contains users.
• Roles - Internal usage within AWS

It is best practice for users to inherit permissions from groups. Always work on the principle that one user is one actual person. Further, the principle of least privilege should always be adhered. For example a finance team does not need to access EC2 instances and scaling controls.

A user can have both programmatic access and password access. Programmatic access provides you with an access key ID and a secret access key for usage with the AWS API, CLI, SDK, and other development tools. Password access enables users to sign in to the AWS Management Console.

After an user has been added you will be presented with access key ID, secret access key and the password. The secret access key and password will only be shown once so it is important to save it in a secure location. These are used for programmatic access. There are also a number of different ways to configure passwords. For example we can allow or disallow users to change their password, make them expire every n days or enforce a specific rule (ie. at least one uppercase etc.). By default an user has no permissions.

Lastly it is possible to add an identity provider to IAM (IAM Federation). You can add for example Github login for logging into the AWS account. This is done through SAML or OpenID Connect. This requires some pre-configured trust between the parties.

IAM users are considered permanent. This is because once their password, access key or secret key is set, they wont change unless the user (or anyone with the proper permissions) explicitly requests it.

A policy in detail

Here is the AmazonEC2ReadOnlyAccess listed.

1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Effect": "Allow",
6            "Action": "ec2:Describe*",
7            "Resource": "*"
8        },
9        {
10            "Effect": "Allow",
11            "Action": "elasticloadbalancing:Describe*",
12            "Resource": "*"
13        },
14        {
15            "Effect": "Allow",
16            "Action": [
17                "cloudwatch:ListMetrics",
18                "cloudwatch:GetMetricStatistics",
19                "cloudwatch:Describe*"
20            ],
21            "Resource": "*"
22        },
23        {
24            "Effect": "Allow",
25            "Action": "autoscaling:Describe*",
26            "Resource": "*"
27        }
28    ]
29}

It describes the statements that lets a user or group read and list certain information from the EC2 instances. The first rule allows the user to list all information on an EC2-instance. Notice the star suffix (*) on the action. Further, similar permissions are given for Elastic Load Balancer, Cloud Watch and Auto Scale. This permission does not give us the ability to start, stop and terminate instances. Further, it is not possible to change anything in the instances. An importent rule to keep in mind is that Deny-policies always takes presedence over Allow-policies. By default everything is denied, so in order to do anything you probably should create some Admin user group with the permissions listed in the Controlling permissions using IAM paragraph.