AWS IAM is one of the core services available in Amazon Web Services. IAM stands for Identity and Access Management. In other words, it means the users of AWS.
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
Basically, AWS IAM is responsible for handling the security of your AWS environment. Every service in AWS uses IAM for its security needs.
In this post, we will understand the various aspects of AWS IAM.
Overview of AWS IAM
IAM or Identity and Access Management is divided into the following parts:
The first and the most basic component of IAM are the users. A user is a physical person.
Basically, all of us are qualified to be users. Each user gets a separate account in IAM. Moreover, this account should not have root privileges.
The root account or user is the most powerful user. It is the user that was used to create a new AWS Account.
The next core component of IAM are the groups.
Basically IAM group is a collection of users. A group can be anything you want for your AWS environment. However, in a usual application area, groups are based around the function its members are supposed to execute.
For example, there could be an admin group, network group, a devops group and so on.
A group can also symbolize a team. For example, the engineering team, network team or the design team.
The use of groups is to share permissions between a set of users. You can assign particular permissions to a group and all the users belonging to that group will automatically inherit those permissions.
Another important component of AWS IAM are roles.
Roles are basically assigned to a machine and are used for internal purposes within AWS resources. In this way, they have a strong distinction from users.
A user is for a person whereas role is for a machine.
Policies are the last component of the AWS Identity and Access Management. They are a key component that binds user, groups and roles together.
Policies are nothing but JSON documents. They define what each of the building blocks of IAM (namely, users, groups and roles) can or cannot do. In other word, we can say that the policies are set of permissions and control access which are written in JSON documents.
As a user, one can write their own policies. However, AWS also contains many default policies that can be directly applied to one of the building blocks.
There are two types of policies in AWS –
- Managed policy: Default policy attached to your AWS resources. An AWS managed policy is a standalone policy that is created and administered by AWS. Standalone policy means that the policy has its own Amazon Resource Name (ARN) that includes the policy name. For example, arn:aws:iam::aws:policy/IAMReadOnlyAccess is an AWS managed policy.
Custom Managed Policy: You can create standalone policies that you administer in your own AWS account, which we refer to as customer managed policies. A great way to create a customer managed policy is to start by copying an existing AWS managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment.
- Inline Policy: are the policies that we create and are embedded directly to user, group or roles.
Important Points for IAM
There are some important pointers with regards to AWS IAM:
- IAM or Identity Access Management has a global Basically, in AWS you can select a particular region to run your resources. And that resource is always tied to that region. However, a building block you create in IAM is available globally.
- Permissions is IAM are governed using Policies. A policy is basically a JSON document that specifies what can or cannot be done by the object to which the policy is assigned.
- You can enable Multi Factor Authentication using AWS IAM. I strongly recommend setting MFA for the root account. This is because a root account is like God mode and if someone gets the credentials for it, they can do a lot of damage.
- While assigning permissions to users in IAM, it is best to follow the principle of least privilege. Every user/group/role should get the minimal amount of permission they require to carry out their tasks. It is important to avoid overpowering a single user or server in the organization.
Golden Rules about AWS IAM
As an AWS admin, it is best to follow the below rules while dealing with Identity and Access Management.
- ONE IAM User per Physical Person. Basically, DO NOT share an account between multiple users.
- ONE IAM Role per Machine.
- NEVER ever share your IAM Credentials with anyone.
- NEVER write your IAM Credentials in a piece of code. If someone gets their hands on your credentials, they can do a lot of damage such as mining bitcoin using your account with you ending up with $20K bill. This has happened, you can google it.
- NEVER use the ROOT Account except for initial setup.
- NEVER use the ROOT IAM User’s credentials.
Features of IAM in AWS:
- Shared access to your AWS account.
- Granular permission: Different permission to different person.
- Multi-factor authentication (MFA)
- Identity Federation
- Eventually Consistent
- Free to use
Accessing IAM in AWS:
There are many ways in which we can access IAM in AWS console.
- AWS Management Console
- Command line Tool (CLI)
- AWS SDK’s
- IAM HTTP API
As you can see, AWS IAM or Identity and Access Management is an extremely important service of Amazon Web Services.
Basically, it forms the backbone of AWS as a whole. Everything you do in AWS uses IAM in some form or another.
Happy AWS Learning!