Identity and Access Management @ CloudThat

Introduction to IAM

Identity and Access Management (IAM) on AWS is an authentication and authorization service to provide access for multiple users to AWS resources. To know about how the permissions work and their hierarchy, check out this link.

How to use IAM to achieve hassle-free and maximum control over the users and resources is completely dependent on the organizational usage and is also continuous learning. Here, I would like to give an insight into how we at CloudThat use IAM on our account, used by all the employees to restrict access and enable cost tracking and management.

Before diving into the details, below are a few of the limits that one needs to be aware of before working with IAM.

The highlighted limits are the ones we need to be aware of in order to smoothly manage IAM for an organization. The limits on the number of policies that can be attached to a user or group, the number of groups a user can be part of and the size of policies that can be attached to a user or a group would play a vital role in formulating the groups and policies for different users. That would in turn assist in controlling and streamlining access to multiple users to AWS resources.

We at CloudThat have employees working with multiple projects which deal with various services across the AWS services spectrum. Controlling and keeping track of accesses has been a constant evolution. We have different levels of users who would need access to the AWS account viz interns, engineers working with various projects, Leads and managers, etc. Based on our learnings, we have evolved to have multiple groups and move a user from one group to another on a request basis in order to give specific access.

Real-time Example of IAM

Let me take a few example groups and explain them in detail. Below are a few of the groups that I would be discussing further

Interns group is for groups of trainees that join CloudThat. This group allows users to work with all the AWS Services but has limits on the sizes and amount of resources that one can launch. For example, a user can create EC2, RDS, and EBS but is allowed to launch only t1.micro or t2.micro instances and with a maximum of 300GB EBS Volumes. As to what the policy looks like, we work with “Explicit Deny”.

Once an employee moves to a specific project, he would be removed from the intern’s group and would be placed into a specific project group which would be “Example Project” in our case. If a project mainly deals with services like API Gateway and AWS Lambda, the group would have permission to all basic services EC2, S3, RDS, etc with additional API Gateway and AWS Lambda. All the services would be having limits specific to the services in order to keep a cap on spending.

The groups like IAM Denied and IAM Access with Conditions, as the name implies, are used to restrict access to IAM itself to maintain sanity on IAM.  IAM Administrators would be the users who have complete access to manage IAM and all the other users would be part of the IAM Denied group, which simply denies all the IAM Actions.

If one needs access to work with IAM, he/she would be removed from the IAM Denied group and placed into IAM Access with Conditions. This group allows access to IAM but restricts a user from adding anyone else to the groups like IAM Administrators, Allow US East, and this group itself. The user would also not be permitted to remove himself or change any metadata of this group itself. A simple statement in the policy would be as below –

Lastly, would also like to bring some attention to a major cost-cutting activity that we employ at CloudThat, which would bring me to talk about denying and allowing access to N.Virginia.  To give an idea as to why we restrict access to N.Virginia, to encourage employees to discard resources when not in use and not leave the resources running all night, we have a cron script running which would delete all the resources every night. This script is not allowed to remove resources from N.Virginia. Hence, by default, all the users would be part of Deny US East group. And if one needs to keep the resources running overnight for any reason, would be placed into Allow US East group, which would allow him to create resources and work in N.VIrginia. The policy to deny one from using EC2 in N.Virginia alone would be as below –

We also make it mandatory for the users to tag all the resources with their names as owners. At present, we only use tags to track spending by each user. One can also build policies based on tags on the resources. To know more about how to use tags for resource access, check out this link.

Conclusion

IAM is always a continuously evolving strategy and based on the limit and requirements one has, coming up with specific IAM groups and policies for the purpose would be a way to achieve manageability and cost optimization on AWS. In the case of organizations with users of more than 5000, the federation would be the way to go. Keep a watch for the next blog on federation access to AWS resources.

Please feel free to give your ideas on how you would use IAM to maximum benefit, which would help all the viewers to get different perspectives.

Learn the 8 Best Practices of Identity and Access Management (IAM) in this blog.

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding IAM and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.