IAM - Getting Started for Beginners
- Amit Dhanik
- Aug 14, 2022
- 7 min read
Updated: Aug 27, 2022
Suppose you(Ram) and your friend(Ashish) have been hired by an organization as a Developer and Tester. You go to the office and it's your first day. You are so excited to start your journey but there is one problem. You are not able to find your specific departments. Of course, both of you will not be working together.
Ram will be working with the Development team, and hence would require permission to all the credentials and tools used by the Development team. He would also be required to know the users of his team well. Thinks how much ghastly it would be if you don't know anyone in the team you are working with!!
Similarly, Ashish would have to be granted permission for the Testing Environment. Additionally, there are some permissions as well which would be told to Ashish, like do not mess with the development code(of course not a real-world scenario as environments of both teams are separated). You understand the issue now of what all steps are to be taken to register a new employee in the organization hierarchy.
Why IAM?
Let's consider a similar scenario as discussed above but from Cloud Perspective. Your organization is working on a full-fledged cloud service(we will be talking AWS here) and hires employees across various departments. All the users are given a username and a password with the help of which they log in to their specific accounts. These users have well-defined permissions as to what they can modify, delete, update or make changes to, as well as have boundaries on what they can and cannot access and make changes to. These users are referred to as IAM users. Each user has a specific role, for eg - Ram is a developer and hence he will be associated with Development Account. Ashish, on the other hand, is a Tester, and he will be associated with the Test Account. Below is a simple diagram explaining this.
ABC's of IAM
IAM stands for Identity and Access Management. As you might have guessed it till now, it's a service that helps you control access securely to the AWS Resources. In AWS, we have only two types of Users -
Root User - When you create a new account for the first time and log into it, you are the Root User and the Account Owner. As an account owner, you have full access to all the resources in your AWS Account. It's like you are the owner of a school. Whatever happens from now on in your account(school) is the sole responsibility of the Root User. Hence, it is always recommended by AWS to create an IAM user with administrator permissions to use for everyday AWS tasks and lock away the access keys for the root user. You don't want any mess up with your root account as you hold all the responsibility!! As the owner of the school, it's your responsibility to register users(students). You set all the permission for the users and are responsible for the billing(admission fees) of each user. You also have the power to terminate a user if he does not behave properly!! You, as the Root owner, have all the power, and with power comes great responsibility. I know this was not needed, but now you know the importance of root account at least.
IAM User - IAM Users are created by the Root user. Why would one need IAM Users(you should know this by now)? If you are working for a corporate, you know that there are thousands of users working along with you, each having different tasks. If you provide root user credentials to every user, each user becomes the owner of the school(every period will be a game period:) ). This means that they can do whatever they wish to, knowingly or unknowingly, which is never safe for any organization. Imagine someone deleting critical files from S3 Bucket, deleting important backup data, or spinning up EC2 Servers that are not needed. All these things should be kept in mind before providing root user credentials to anyone. I will repeat - It is always recommended by AWS to create an IAM user with administrator permissions to use for everyday AWS tasks and lock away the access keys for the root user. You don't want any mess up with your root account as the root account user has all the powers!!
IAM is mainly used for two purposes -
Authentication - Who can access what resources? You do not provide each user with access to all the resources. You limit the resources according to the User. For eg - a salesperson might not need any access to EC2 Machines, so you limit his access to the services he need only. Similarly, a developer might need access to Cloudtrail and cloud watch to see the logs and EC2 machines to run the code. So, we create an IAM user which has permission to access all these resources.
2. Authorization - How they can use the resources?
Key Terminologies for IAM
Users - Users are the people/employees of an organization. You create IAM Users for anyone who wants to access your AWS account. When you create an IAM User, each user gets a unique set of security credentials with the permission you grant. Remember Ram and Ashish, they are the users.
Groups - A group is a collection of users, and helps in segregating users belonging to the same job function. This way you don't have to specify permissions for all the individual users which otherwise would become a tedious task to manage. Hence we have groups for specific job functions. For eg - Organisations have groups of Developers, Tester, Administrators, etc. All these groups are made with the permission that would be required by users of these groups. Users are then added directly to these groups, and all the permissions are thus inherited by the users. This is a convenient way, and if ever some permissions have to be revoked or added, it can be directly attached/removed from the group, and thus all users under that group would have the same changes. Remember, each user in the Group inherits the permission of the group.
Policies - Policies are the permissions that you attach to a User/Group. The permissions are normally specified in JSON format. For eg, if you want a user to have administrator access, you can attach the following policy to the user. AWS supports six types of different policies, which you must read once. You can find them here.
Note - You can create your own set of policies, which are referred to as customer-managed policies. As AWS States - Customer managed policies are standalone policies that you administer in your own AWS account. You can then attach the policies to identities (users, groups, and roles) in your AWS account.
So, the basic idea here is that we create Groups first, attach specific policies to those groups, and then we create users and attach them to the groups according to the policies that will be defined for each user. If a user is a developer, he will be attached to the group developer, which will be having IAM Policies like access to EC2, S3, Cloudfront, etc.
Before we move to discuss Roles, let's discuss a bit about Permission Boundaries. Suppose you have to define some specific well-defined permission for a user and bar him from using any other services. Here permission boundaries come into play. Let's suppose Sam has to be only allowed access to EC2, RDS, and Route53. You can create the following rules to create Permission Boundaries for Sam.
{
"Version": "2021-20-7",
"Statement": [
{
"Effect": "Allow",
"Action": [
"RDS:*",
"Route53:*",
"EC2:*"
],
"Resource": "*"
}
]
}
This policy will set maximum permission for Sam and he can perform all operations in RDS, Route53, and EC2. Sam cannot make use of any other services provided by AWS. When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
There are a variety of policies that can be applied but are for advanced learning. You can read more about permission boundaries here.
Roles
Roles - Let's see what AWS's definition for a Role is - An IAM role is an identity you can create that has specific permissions with credentials that are valid for short durations. Roles can be assumed by entities that you trust. Got confused? Me too! Let's try to understand this with the help of an example.
While Users and groups are created for individual users, roles are not for AWS Users. Instead, they are for AWS Resources. Let's think of a practical use case for this. Suppose you have some program running on your Virtual Machine(EC2 Instance). The programs want access to your Database, RDS for instance. How will you do this? Here Roles come into play. Roles are something that are assumed by machines or by services of AWS. Roles are assigned to the AWS Services so that they can communicate with other services without any problems. But sometimes people can also get this role.
Suppose you are working for a client, and they are highly into security. The organization will first give you access to their machines, using some role, and for you to log in to their system, you have to enter a key that is renewed every time you try to log in. So, in this case, a role can be assigned to the user as well. You can read this more here.
AWS allows us to create Roles for 4 different types -
AWS Services - You can create roles for EC2, Lambda, and other AWS Services
Another AWS Account
Web Identity - For eg - Cognito
SAML
Note - It's not necessary that always service is assigned a Role. Sometimes people can also be assigned Roles.
Additional Reading
If you work in an organization, you would have often set up your personal password for logging into the computer/laptop. You must have noticed that it comes with a specific set of instructions, as well as it needs to be updated every 1 month or so. This, in AWS, is achieved via Account settings under IAM.
If you click on the change password policy, you can see all the conditions listed out. If you apply these on the root user account, all of these are naturally transferred to IAM users created as well.
That covers all the basics you need to know about IAM. There are some best practices that you must keep in mind, which you can read below. Happy reading !!
Comments