IAM Authorization Hierarchy
Identity and Access Management (IAM), is a service that authenticates and authorizes users and resources within an AWS account. Although authentication is quite straightforward and easy, viz. You can create groups, users, credentials, and share them with others, but authorization is a tricky task on IAM. S3 Bucket policies, Bucket ACLs, SNS Topic Policy, and SQS Policies, which are all resource-level permissions, work in conjunction with IAM permission. IAM is a user perspective. Other permissions are resource-based.
Many times, I get asked questions such as “Which permission is more important?” or “What if two permissions have contradicting permissions? What would be the best way to use them?” or “What happens if no permissions are granted?” This blog will clarify these ambiguities while using IAM, S3 bucket policy policies, or any other mode permission on AWS.
AWS has always adhered to a minimum permission policy for all services. It means that if a resource doesn’t have permission, it will be considered a “Deny”. After the initial deny decision, the final decision to allow or deny would be based upon the “Explicit” permissions and the denies listed in the permissions. This simple flowchart should give you an idea about what the decision would be based on certain conditions. This applies to all permissions in AWS.
What are these Explicit Allow and Deny Conditions? Any policy that has Effect as Allow is an explicitly Allow policy, and any policy that has Effect as Deny a explicit Deny policy. There are permissions for aws that are not JSON documents like S3 Bucket aCLs. These permissions are inherently explicit. You would be able to authorize the use of specific conditions. S3 ACLs allow you to explicitly allow everyone/AWS Authenticated users to read/write the bucket/object.
Let’s say that an IAM user has below two policies. Now let’s see what the overall effect would be. If the source IP of the user is 126.96.36.199.111, would the user be allowed access to EC2?
If you answered “Allow”, then you are correct. Both policies have explicit allows and there is no explicit deny of source ip 188.8.131.52. Policy 2 allows users to log in only from 184.108.40.206, but not from 220.127.116.11.111.111. Policy 1 allows all EC2 actions from any location. Our flowchart shows that if the answers are No to the first explicit deny condition then the execution would move on the next explicit allow condition. This would return to Yes, since Policy 1 explicitly allows access to all EC2 actions from anywhere.
I hope this helps you get a better understanding of how authorization works on IAM. It is important to work with explicit denials. It is important to ensure that all restrictions are explicitly denied if a user is permitted to use a service. This gives you a better control. You can leave your questions and suggestions in the comments section below.