How to use IAM to achieve hasslefree and maximum control over the users and resources is completely dependent on the organizational usage and is also a 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 few of the limits that one needs to be aware of before working with IAM.
|Groups in one AWS Account||100|
|Users in one AWS Account||5000|
|Groups a user can be member of||10|
|Customer Managed Policies for an AWS Account||1000|
|Versions of managed policies per policy||5|
|Managed Policies that can be attached to a user, group||10|
|Size of each managed policy||5120 Characters|
|Inline policies that can be attached to a user, group||Unlimited|
|Aggregate inline policy size for a user||2048 Characters|
|Aggregate inline policy size for a group||5120 Characters|
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 a user or group, 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 to access to the AWS account viz interns, engineers working with various projects, Leads and managers etc. Based on our leanings, 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.
Let me take few example groups and explain what I mean. Below are few of the groups that I would be discussing further
|Interns||New trainees joining and beginning to use AWS|
|Example Project||Employees working in a specific project|
|IAM Administrators||Employees managing IAM – Complete IAM Access|
|IAM Denied||Users who do not have access to IAM|
|IAM Access with Conditions||Users having access to IAM but with few restrictions|
|Deny US East||Users not having access to N.Virginia|
|Allow US East||Users having access to N.Virginia|
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, EBS but is allowed to launch only t1.micro or t2.micro instances and with a maximum of 300GB EBS Volumes. As to how the policy looks like, we work with “Explicit Deny”.
Once an employee moves to a specific project, he would be removed from interns group and would be placed into specific project group which would be “Example Project” in our case. If a project mainly deals with services like API Gateway and Lambda, the group would have permission to all basic services ec2, s3, rds,etc with additional API Gateway and 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 IAM Denied group, which simply denies all the IAM Actions.
If one needs access to work with IAM, he/she would be removed from 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.
To conclude, IAM is always an continuous 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 case of organizations with users more than 5000, federation would be the way to go. Keep a watch for 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.
Leave a Reply