- Service Delivery Program
- About Us
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 126.96.36.199?
If your guess is “Allow”, you have the right idea. In both the above policies, there is no explicit deny for source ip 188.8.131.52 and both are explicit allows. Although Policy 2 explicitly allows the users to login only from 184.108.40.206 and not from 220.127.116.11, 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.
Our support doesn't end here. We have monthly newsletters, study guides, practice questions, and more to assist you in upgrading your cloud career. Subscribe to get them all!