IAM Authorization Hierarchy

May 5, 2015 | Comments(2) |

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.

iam_permissions

 

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?

iam_policy_example

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.


2 Responses to “IAM Authorization Hierarchy”

  1. Rajesh

    hi Sankeerth
    Great Article, thanks
    Can I request you to add such examples for various types of policies / services

    Reply
  2. IAM @ CloudThat | CloudThat's Blog

    […] 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. […]

    Reply

Leave a Reply