Policy evaluation

As your environment grows, so will your users, groups, roles, and resources. As a result, there will be times when an identity will have multiple policies that affects it, so how does AWS manage the logic of these policies?

When a request is received to gain access to a resource within AWS, the following four steps are performed to determine the permissions allowed:

1. Authentication: AWS determines who the principal of the request is by way of authentication.
2. Determine the context of the request: The access request is processed to define which policies should be used for permission verification. In this step the actions, resources, principals, environment data, and resource data are examined.
3. Policy evaluation: AWS evaluates the policy types being used as a specific order is applied when processing the policies to determine the evaluation of permissions within a single account. Policies will be evaluated in the order of identity-based, resource-based, IAM permissions boundaries, and SCPs.
4. Permission result: After the evaluation of policies has been carried out, access is either granted or denied.

As long as Allow exists in any one of the policies associated with the request, then access will be allowed for the relevant action. However if Deny exists in any of the policies that apply to the same resource and action as Allow, then access will be denied.

Let’s look at an example to help explain this policy logic.

User Lisa has got an identity-based policy attached that allows a subset of S3 permissions, including s3:putobject and s3:getobject, against a bucket of MyBucket. However, in addition to this, a bucket policy attached to MyBucket allows additional permissions to the principal Lisa user with permissions of s3:deletebucket and s3:deleteobject. What permissions does Lisa ultimately have?

In this instance, all the permissions are set to Allow, and so the permissions are accumulated, and the end result will be that Lisa has the following:

S3:putobject
S3:getobject
S3:deletebucket
S3:deleteobject

If at this point an IAM permission boundary was associated to Lisa that had a Deny effect for the action of S3:deletebucket against the resource of MyBucket, then the permissions for Lisa would be reduced to the following:

S3:putobject
S3:getobject
S3:deleteobject

Again, if at this point an SCP was added to the account where the Lisa identity was created that had a Deny effect for the action of S3:putobject against the resource of MyBucket, then Lisa’s permissions would be reduced to the following:

S3:getobject
S3:deleteobject

Remember, any deny action will overrule any allow action.

Ensure you have a good understanding of policy evaluation as you will need to understand how AWS manages this to resolve permission and access control-related issues. To do this, you will also need to be able to read policies effectively to understand the exact permissions they are enforcing.