IAM Authorization Hierarchy

Identity and Access Management (IAM) is the service that provides a authentication and authorization control for users and resources in ones AWS account. Although authentication has been quite simple and straightforward, viz. one can create groups, users and credentials for the users and share the same, authorization is quite a trick on IAM. Also, S3 Bucket policies and Bucket ACLs, SNS Topic Policies and SQS Policies are other resource level permissions which work in tandem with IAM permission. While IAM is from a users perspective, others are from a resource perspective.

Many a time, I get questions like “Which permission gets higher priority?” or “User is in two groups with contradicting permissions, what would be effective?” or “What happens when no permissions are given?”. This blog is to clear these kind of ambiguity while using IAM, S3 bucket policies or any other mode of permission on AWS for that matter.

AWS has always been adopting least permission policy across all the services. Meaning, if no permission about a specific resource is  specified, it would be a “Deny”. Post the initial deny decision, the final decision of deny or allow would be based on “Explicit” allows and denies specified in the permissions. Below is simple flowchart which should give you an idea of what would the decision be, based on given conditions. This works across all the permissions present in AWS currently.

Now, what are these Explicit allow and deny conditions? One can guess that any policy with Effect as Allow is an explicit Allow and of course with Effect as Deny  is an explicit Deny. But there are also permissions on aws which are not a JSON document like S3 Bucket ACLs. These are inherently Explicit Allows. Default would be complete Deny and you would be given option to authorize using specific conditions. For example, in S3 ACLs, you explicitly allow either Everyone/AWS Authenticated Users to Read/Write the bucket/object.

Let’s consider an IAM user with below two policies and guess what would be the overall effect. Would the user be allowed to use EC2 if the source IP is 111.111.111.111?

If your guess is “Allow”, you have the right idea. In both the above policies, there is no explicit deny for source ip 111.111.111.111 and both are explicit allows. Although Policy 2 explicitly allows the users to login only from 102.102.102.102 and not from 111.111.111.111, Policy 1 explicitly allows the all EC2 actions from anywhere. According to our flowchart, as the answers would be No  for the first explicit deny condition, the execution would move on to the next explicit allow condition which would return to Yes as Policy 1 explicitly allows access without any condition.

So, I hope you have a better idea on how the authorization works on IAM now. One advice would be to always work with explicit denies. If a user is allowed to use a service, try to make sure all the restrictions on the services would be explicit denies, which gives a finer control. Please leave your queries and ideas in the comments section below.

WRITTEN BY CloudThat

CloudThat is a leading provider of cloud training and consulting services, empowering individuals and organizations to leverage the full potential of cloud computing. With a commitment to delivering cutting-edge expertise, CloudThat equips professionals with the skills needed to thrive in the digital era.