AWS Identity and Access Management
Photo by Moja Msanii on Unsplash

AWS Identity and Access Management (IAM) is a web service for securely controlling access to AWS services. With IAM, you can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users and applications can access.

AWS account root user

The role of the root account is to create AWS users
The role of the root account is to create AWS users

It is created by default when registering on AWS. It shouldn’t be used except for creating AWS accounts setup. We can even imagine that it is used to create the first AWS account with administrator rights, and that’s it.

IAM User and Group

An IAM User is one physical person and only one :

  • AWS user accounts must be protected by a strong Password Policy and Multi-Factor Authentication (MFA) to access AWS Management Console.
  • For programmatic access via CLI (AWS Command Line Interface) from a console or SDK (AWS Software Development Kit) from an application, users can use Access Keys (an Access Key ID + an Access Key Secret) to access AWS Services.

A IAM Policy grants a specific set of permissions and can be linked to any IAM identity: User, Group or Role.

User permissions (IAM Policies) are attached either at the user level directly or even better, at the Groups level to which users belong.

Multiple Groups can be attached to Users
Multiple Groups can be attached to Users

You should never EVER share your AWS User account or your Access Key!!

How to use Access Key?

Let’s take the connection example to an EC2 instance.

  1. Set the file permissions To secure the PEM file containing your Access Key ID and its Secret Key, AWS verifies that your PEM file permissions are secure. That means you should always set these permissions before using it:
chmod 0400 <ACCESS-KEY-FILE>.pem
  1. Connect to your instance On Linux instances, username is ec2-user. Let’s ssh into it:
ssh -i <ACCESS-KEY-FILE>.pem ec2-user@<PUBLIC-IP-SERVER>

IAM Role

All security in AWS is based on IAM Roles and this is probably the most difficult part to understand.

Let’s see the concepts of IAM Roles IAM through a progressive approach.

The summury version (but not entirely accurate!)

A IAM Role authorizes an AWS Service to access information from another AWS Service.

In the example below, an EC2 Instance uses an IAM Role to access a S3 Bucket in Read-Only:

An IAM Role grants access to an EC2 instance to access an S3 bucket
An IAM Role grants access to an EC2 instance to access an S3 bucket

The long version (but more complex!)

In order to fully understand the concepts behind IAM Roles, we need to define some terms specific to AWS.

IAM Identity

  • IAM User and IAM Role are both IAM Identities
  • It has Permissions Policies that determine what identity can and cannot do in AWS

So, User and Role are the same concept in AWS.

What differentiates them:

  • A User is associated with an individual in a unique way and has Long Life Identifiers, such as a password or access keys
  • A Role is for anyone who needs it (so it may be a User) and has temporary identifiers, for the duration of the Role session

AWS Service Role

This is a Role for a Service, which is a set of permissions that allow this Service to access, in your account and on your behalf, the AWS Services it needs

It is therefore a Role intended for a Service

Trust Policy

  • A Trust Policy defines the Principales you trust to endorse a Role.
  • A Principale can be User, Role, AWS account or Service.

Therefore one can exactly define to whom a Role is intended to

What it does

Some examples of using Roles (not exhaustive and in no particular order!):

  1. Allow a Developer to temporarily access, in read-only, a Production environment
  2. Allow a Load Balancer to (1) read CloudWatch metrics and (2) create new EC2 instances as required
  3. Allow a certain application to have read/write access to a specific directory of a S3 Bucket

What to remember

It is always best to use a Role to manage access to AWS resources

Jean-Jerome Levy

Written by

Jean-Jerome Levy

DevOps Consultant

Seasoned professional in the field of information technology, I bring over 20 years of experience from working within major corporate IT departments. My diverse expertise has played a pivotal role in a myriad of projects, marked by the implementation of innovative DevOps practices.