Identity and Access Management (IAM) in AWS
Introduction to AWS
AWS, I believe each one of us have heard this buzz word, also this has been popular and ruling the IT world. However, there are many IT aspirants among us who still wonder, how and from where they should start learning AWS. To be honest it’s a spaghetti bowl. I am saying this because when you login to AWS console and click on service it will show you all the services as shown in below image.
And this is not to scare you. Once you know where to start, you will be able to connect logically with all the services easily.
Therefore, after studying and analyzing, I came to the conclusion that starting point of AWS should be the IAM service and I will be explaining same further in this post.
To proceed further, I would recommend you to please create you AWS account and get 1 year free tier access which will help you too do hands-on and understand the services better.
You can check on this link for full offer terms
Alright, so let’s start and learn the first AWS service, before that l will just ask a simple question what would be the first step you will think while creating an application or any service.
If you just thought security bingo! You have put your step forward to learn 1st service i.e.
IAM (Identity and Access Management)
IAM enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, use permissions to allow and deny their access to AWS resources. IAM is a feature of your AWS account offered at no additional charge.
This is core of AWS as it manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources.
Now you might scratch your head wondering what are policies. Well it is JSON object in AWS that, when associated with an identity, defines their permissions. AWS evaluates these policies when an IAM user or role makes a request.
Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents.
AWS supports six types of policies: identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, ACLs, and session policies.
Every service in AWS used IAM for security purpose.
Let’s understand this by example:
Key points here are:
1) Users for physical person, Roles are for machines.
2) Policies will define what users/groups/roles will be allowed to perform.
Deep Dive into IAM policies
IAM comes with managed policies which amazon provides from itself and we can also create our own policies.
IAM has a global view. Now what does that mean? – That means when you create a User or group or a role in AWS account it will be accessed across all the regions and that also make sense.
Note- (AWS regions are geographically divide it is possible that you can see some service in one region and not in other region. To understand this by example: when you stream content on Netflix/amazon you might not see USA content In Asian countries as they are region specific.)
We can enable MFA (Multi Factor Authentication) for all users it’s a token based authentication similar to RSA device.
The best practice is to give users the minimal amount of permissions they need to perform any task.
Now, IAM comes with managed policies which amazon provides from itself and we can also create our own policies.
IAM has a global view. Now what does that mean? – That means when you create a User or group or a role in AWS account it will be across all the regions and that also make sense.
Note- (AWS regions are geographically divide it is possible that you can see some service in one region and not in other region. To understand this by example: when you stream content on Netflix/amazon you might not see USA content In Asian countries as they are region specific.)
MFA for users
We can enable MFA (Multi Factor Authentication) for all users it’s a token based authentication like RSA device.
Now, the best practice is to give users the minimal amount of permissions they need to do their job.
Best practices to use IAM:
- First and the most important point to remember is never user root account and you might question why should I not use it – because root user gives full access to all your resources for all AWS services, including your billing information
You cannot reduce the permissions associated with your AWS account root user access key.
- You might have learned sharing is caring and out of generosity you shared credential to help other learning AWS services, sounds helpful.
However, here it will cost you in all aspects from your billing to your resources and in worst case you might not able to use your account again still pay the bill, scary right!
Therefore, remember, to allow your users individual programmatic access, create an IAM user with personal access keys.
- Use groups to assign permission to IAM users, just add new user to the security groups you have created.
That way, you can make changes for everyone in a group in just one place. As people move around in your company, you can simply change what IAM group there IAM user belongs to.
- Use Customer managed policy instead of inline policies. The main benefit of using these policies is that you can view all of your managed policies in one place in the console.
Basically, inline policy is one to one mapping created by user. On the other hand, a managed policy is a standalone policy which can attached to multiple entities.
Steps to convert inline policy to managed policy using the instructions below.
- Sign in to the AWS Management Console and open the IAM console.
- In the navigation pane, choose Groups, Users, or Roles.
- In the list, choose the name of the group, user, or role that has the policy you want to remove.
- Choose the Permissions tab. If you chose Groups, expand the Inline Policies section if necessary.
- For groups, choose Show Policy next to the inline policy that you want to remove. For users and roles, choose Show n more, if necessary, and then choose the arrow next to the inline policy that you want to remove.
- Copy the JSON policy document for the policy.
- In the navigation pane, choose Policies.
- Choose Create policy and then choose the JSON tab.
- Replace the existing text with your JSON policy text, and then choose Review policy.
- Enter a name for your policy and choose Create policy.
- In the navigation pane, choose Groups, Users, or Roles, and again choose the name of the group, user, or role that has the policy you want to remove.
- For groups, choose Attach Policy. For users and roles, choose Add permissions.
- For groups, select the check box next to the name of your new policy, and then choose Attach Policy. For users or roles, choose Add permissions. On the next page, choose Attach existing policies directly, select the check box next to the name of your new policy, choose Next: Review, and then choose Add permissions.
You are returned to the Summary page for your group, user, or role.
- For groups, choose Remove Policy next to the inline policy that you want to remove. For users or roles, choose X next to the inline policy that you want to remove.
IAM Use Case:
Integrate with your corporate directory
You can use AWS (IAM) to enable users to sign in to their AWS accounts with their existing corporate credentials. To help you scale up as you add more AWS accounts, you can use AWS Single Sign-On (SSO) to manage SSO access to multiple AWS accounts and business applications centrally. You also can add federation support to your own web and mobile applications by using Amazon Cognito.
For example – you can create your Active Directory using AWS Directory Services
AWS Managed Microsoft AD
• Create your own AD in AWS, manage users locally, supports MFA
• Establish “trust” connections with your on- premise AD
AD Connector
• Directory Gateway (proxy) to redirect to on- premise AD
• Users are managed on the on-premise AD
Simple AD
• AD-compatible managed directory on AWS
• Cannot be joined with on-premise AD
Now let’s see the backbone of all other services, this is STS – Security Token Service.
AWS STS – Security Token Service
- Allows to grant temporary and limited access to AWS resources.
- Token is valid upto 1 hout (must be refreshed)
- Assume Role
i) Within you own account for enhance security.
ii)Cross account acces: assume role in the target account to perform actions there. - Get Session Token
i) For MFA, from a user or AWS account root user.
Therefore, we can see STS is really at the centre of providing our users our aplications,
tokens that allow them to talk to our resources.
Use case for STS – How to assume a role.
• Define an IAM Role within your account or cross-account.
• Define which principals can access this IAM Role.
• Use AWS STS (Security Token Service) to retrieve credentials and impersonate the IAM Role you have access to (AssumeRole API)
• Temporary credentials can be valid between 15 minutes to 1 hour.
Alright! now you are proficient to set up an IAM services to your organization.
Lastly, let’s summarize what we have learned:
- IAM has a global view. (across all AZ)
- One IAM user per physical person
- Permissions are governed by policies which is a JSON object.
- IAM credential should never be shared.
- Never use root IAM credentials.
- MFA (Multi Factor Authentication) can be setup.
- IAM has predefined policies we can create our own policies too.
- AWS – STS for temporay acces to all services.
- Provide least amount of permission to the users which they need to do their job.
I believe, you have a fair understanding of IAM i.e. how to use it and when to use it. We also learned how essential it is for AWS.
Hope this post helps you in understanding AWS IAM.
In my next post I will walk you through step by step with IAM to set up a user groups roles and how to create policies. Till then keep exploring mindsmapped.com.
Never stop Learning as life never stops teaching 🙂