All articles in
Identity and Access Management
AWS Policy Evaluation logic for the five AWS policies made simple
In this article, we will discuss the AWS policy evaluation logic for the five AWS policies – IAM, Resource, SCP, Permissions Boundary and Session, and make it simpler for AWS Professionals to understand. Policy evaluation can be a nerve wrecking topic for many and it can be especially challenging in large organizations where multiple teams are handling different types of AWS policies since conflicts between policies can cause undesirable effects on downstream users/systems.
This is the second time we are discussing Policy Evaluation as part of the AWS Security Masterclass course. In the first iteration, we discussed policy evaluation when only IAM and Resource policies are at play (Policy Evaluation for IAM and Resource Policy). We recommend taking a look at that article before you start here.
It’s true that policy evaluation can be a very complicated topic to digest when you are troubleshooting an access issue or trying to configure an environment to work as expected, but if you look at the five AWS policies with the lens of below two policy types, it becomes rather simple to understand –
Permission Policies: Policies that have the ability to grant permissions
Let’s clear one thing first, the only policies that can grant permissions to an identity are IAM policy and Resource policy. If you have not provided any ALLOW statements for the permission being evaluated in either of those 2 policies, your access request would be implicitly denied (unless you are the root user which has full access by default). What happens if both IAM and Resource policy have permissions and they conflict, how is total residual permission evaluated in this case? Good question, we have that covered as part of our article – Policy Evaluation for IAM and Resource Policy, and if you read it, you should now have a clear understanding of the residual permissions when only IAM and Resource policy are present in intra-account and cross-account access use cases. Here is a gist of residual permissions:
- For intra-account access, the total permission applicable to an AWS principal is the addition of the permissions provided in the IAM policy and Resource policy.
- <EXCEPTION> Only exception to this is the KMS resource policy where a permission needs to be added to both policy types to reach an ALLOW.
- On the contrary, for cross-account access, the total permissions applicable to an AWS principal are the ones that are present in both the IAM policy (attached to the principal requesting access) and the resource policy.
Limiting Policies: Policies that have the ability to “only” limit permissions
The remaining three policies – Service Control Policy (SCP), Permissions Boundary and Session Policy are only limiting the maximum permissions that are allowed by the Permission Policies (IAM policy and Resource policy). This means that even if a permission is allowed by the Permission Policies, if that permission is “not” explicitly allowed in the limiting policies (IMPLICIT DENY) or if explicitly denied, the access would be denied.
- SCPs are applied at an AWS account or OU level which is onboarded to AWS Organizations and have no exceptions to their limiting powers and that includes the AWS Root User. This means that whatever maximum permissions are applied in SCP, that should be applicable to even the Root user. Unfortunately SCPs work only at an account level or OU level (multiple accounts), and if you need granular limitations – at an identity or session level, you will have to go to the other 2 limiting policy types.
- Permission Boundaries are applied at an Identity level – AWS User or AWS Role and can be used to set the maximum permissions for both of these types of identities. Session Policies limit the maximum permissions for a Session which is applicable whenever an AWS Role is assumed or a user is federated. There is one exception to the limiting powers of both Permission Boundaries and Session Policies
- <EXCEPTION>If a Resource policy allows a permission from the same AWS Principal (IAM user, Role Session, Federated User) which is making the request, then even if that permission is “not” explicitly allowed in Permissions Boundary or Session Policy, it will still be allowed. Please note that the allowed principal has to be the same User or “session” principal which is making the request. See the table below for explanation:
| Principal making the request | Principal allowed in Resource policy | Is Exception applicable? |
|---|---|---|
| AWS User | AWS User | Yes |
| Role Session | Role | No |
| Role Session | Yes | |
| Federated User | AWS User | No |
| Federated User | Yes |
Keep in mind that neither Permissions Boundary nor Session Policy are applicable to the AWS Root user.
Order of AWS Policy evaluation
Eval Check 1 → [EXPLICIT DENY] If any of the 5 policies have an Explicit Deny, then access is denied.
Eval Check 2 →[IMPLICIT DENY] If the AWS account is onboarded to AWS Organizations and has a SCP attached, and it does not have an Allow for the permission being evaluated, then the access is denied.
Eval Check 3 → [IMPLICIT DENY] If there are no ALLOW statements after the residual permissions from the Permissions policies (IAM policy and Resource policy), the access is implicitly denied. –
- <EXCEPTION>Please note that even without any IAM or Resource policy, AWS Root user has full access to AWS so this Eval Check does not apply to it. Learn more about it from AWS users article.
- <EXCEPTION to an EXCEPTION> KMS resource policies can limit access of the AWS Root User. Learn more about it from the AWS Resource policies article.
Eval Check 4 → [IMPLICIT DENY] If there is an applicable Permissions Boundary or Session Policy (first Permission Boundary is evaluated) and if it does not have an Allow for the permission being evaluated, then the access is denied.
- <EXCEPTION>Only exception to this is when a Resource policy allows the permission for the “same” Principal (IAM user, Role Session, Federated User) as the one making the request, in that case this allow overrides the implicit deny of Permissions Boundary and Session Policy.
- Root users cannot have Permissions Boundary or Session Policy attached to them, so this Eval Check doesn’t apply to the Root User.
✅ If none of the above four Eval checks are true meaning none of them result in Deny, then the access is ALLOWED.
If you understand the two intrinsic policy types – permission and limiting, exceptions applicable to them and the order of AWS policy evaluation, then you shouldn’t have any problems understanding the AWS policy evaluation landscape. Here is a mind map to help you remember the concepts discussed in this article:
Follow us on: