AWS Identity and Access Management
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
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.
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.
- 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- 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:
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!):
- Allow a Developer to temporarily access, in read-only, a Production environment
- Allow a Load Balancer to (1) read CloudWatch metrics and (2) create new EC2 instances as required
- 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
