CloudThat Manages Identity and Access

1. Introduction to IAM
Identity and Access Management (IAM on AWS) is an authorization and authentication service that allows multiple users to access AWS resources. This link explains how permissions work and the hierarchy.
How to use IAM to have hassle-free and maximum control of users and resources depends on the organization usage. This is also a continuous learning process. I will be sharing with you how CloudThat uses IAM to manage our account. This is used by all employees to limit access and track costs.
Before we get into the details, here are some limitations that you need to know before you start working with IAM.

These are the limits we need to be aware to manage IAM in an organization. These limits, which limit the number of policies that can attach to a user/group and the number of groups that a user can join, and the size of policies that can attached to a person or group, are crucial in determining the policies and groups that will be used by different users. This would allow for more efficient access control and streamlining of multiple users to AWS resources.
CloudThat has employees who work on multiple projects that deal with different services. It has been a continuous evolution to control and keep track of accesses. There are many levels of access required to AWS account: engineers working on different projects, interns, managers, leads, and so forth. We have learned from our mistakes and have developed multiple groups that allow users to be moved between them on a request basis. This allows us to grant specific access.
2. IAM Real-time Example
Let me give you a few examples and explain them in more detail. Below are some of the groups I would like to discuss further.
The Interns group is for trainees who join CloudThat. This group allows users access to all AWS Services, but there are limits on the resources and sizes that can be launched. A user can create EC2, RDS and EBS, but they are limited to launching t1.micro and t2.micro instances. They also have a maximum of 300GB EBS Volumes. We use “Explicit Deny” as our policy.

Once an employee is assigned to a project, he would be removed as an intern and placed in a project group. In our case, “Example Project”. If a project focuses on services such as API Gateway or AWS Lambda then the group would be granted permission to access all basic services EC2, S3, RDS and additional API Gateway. To keep spending under control, all services would have limits that are specific to them.
IAM Access with Conditions and IAM Denied are two groups that can be used to limit access to IAM to preserve IAM’s sanity. IAM Administrators are the users who have full access to manage IAM. All other users would be part IAM Denied, which simply denies all IAM Actions.
If a user needs to access IAM, they would be removed from IAM Denied and placed in IAM Access with conditions. This group grants access to IAM, but it restricts the user from adding others to groups like Allow US East or IAM Administrators. This group would not allow the user to delete or modify any metadata. The policy could be summarized as follows:

Last but not least, I would like to draw your attention to a cost-cutting activity we use at CloudThat. This would allow me to discuss denying and allowing N.Virginia access. To give you an idea of why we restrict N.Virginia access, and to encourage employees not to leave resources running all night, there is a cron script that would delete all resources.