Introduction to IAM in Amazon web services
Cloud is one of the booming technology. And AWS is one of the leading cloud service providers. In this article, we will understand what is IAM(Identity and Access Management), which is essential for everyone to work with AWS. This article is going to be brief introduction of what you can do with IAM and Why you need it.
When a user creates an AWS account, the account is created as root User. Root user is the most powerful user and can access all the resources, billing details, other user details that are associated with this root account etc.
AWS Signup Page:
AWS Login page:
It can be fine if you are working alone but imagine being part of an enterprise and creating resources where you have deployed critical applications. Now will you be willing to share the root credentials to the whole team? Is it secure? What if someone deletes some critical resources by mistake or unintentionally such as database? What if the root credential goes into wrong hands? IAM comes to rescue here. Lets discuss how.
What is IAM?
IAM stands for Identity and Access Management. IAM provides the infrastructure necessary to control authentication and authorization for your account. It allows you to create IAM users and each user can be assigned specific set of permissions. This will give restricted access to each user.
IAM Dashboard:
Here we can see two options in the side bar: Access Management and access reports . And in center we can see IAM resources. Resources include User Groups, Users, Roles, Policies and Identity providers.
IAM Resources:
Users:
While creating the AWS account, root user is created. Instead of sharing your root user credentials with others, you can create individual IAM users within your account with custom permissions. IAM users are not separate accounts. They are users within your account. Each user can have its own password for access to the AWS Management Console.
An IAM user doesn’t have to represent an actual person. You can create an IAM user in order to generate an access key for an application that needs AWS access.
Note: Only service control policies (SCPs) in organizations can restrict the permissions that are granted to the root user.
Policies:
A user or application can be authenticated if it is a valid identity(user, group, role) in AWS.
But does that tell AWS which resources that identity can access? No! We must tell AWS about the Permissions.
To Decide which user can have access to which resources, policies are defined.
A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. When a user makes a request for a resource, AWS evaluates the policies for that particular user and allows/denies the access.
Most Policies are stored in AWS as JSON files. These policy files are attached to a user or a role.
Example:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}There are various types of policies that we can define: Identity-based policies, Resource-based policies, Permissions boundaries, Organizations SCPs, Access control lists (ACLs), Session policies.
User Group:
A User group is collection of IAM Users. User groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users.
If five users require same permissions, instead of assigning each user the same set of policy five time, a user group can be created. And required policy can be attached to the group itself. In future if someone new joins, who require same set of policies then you can simply add the new user to the group.
Roles:
Similar to Users, Roles can also be defined. But instead of being associated with the single user or application, A role can be used by anyone who needs it. Unlike Users, Roles don’t have long term passwords but temporary security credentials.
Roles can be used in cases where you don’t want to share the access key with a third party app or when you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. Or, you might want to grant access to your account to third parties so that they can perform an audit on your resources.
Identity Providers:
idP(identity providers) are external medium of authentication. If you already manage user identities outside of AWS, you can use IAM identity providers instead of creating IAM users in your AWS account.
With an IdP, you can manage your user identities outside of AWS and give these external user identities permissions to use AWS resources in your account. This is useful if your organization already has its own identity system, such as a corporate user directory.
Your external users sign in through a well-known IdP, such as Login with Amazon, Facebook, or Google. You can give those external identities permissions to use AWS resources in your account. IAM identity providers help keep your AWS account secure because you don’t have to distribute or embed long-term security credentials, such as access keys
With combination of Users, Roles, Policies, and Groups we can ensure higher security for the applications and resources.
Hope the article gave you some insight. Follow for more content. And Feel free to share any feedback in comments. 😊
Resources:
AWS comes with amazing documentation. To explore More:
Policies and Permissions: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
Roles:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
User Groups:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html
Identity Managers:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html
