AWS policy evaluation logic

As builders in the IT industry, we have all encountered situations where we are denied to perform an action on a given resource. When the company adopts a complicated and constrained permissions mechanism, identifying the root issue of a deny message requires a lot of debugging and a comprehensive understanding of the policy evaluation logic.?

In this article, I am explaining the policy evaluation logic in the AWS Cloud.

First, let’s define the technical concepts we will use in this article:

• Permission policy document: it is a JSON document used to define either an “Allow” or an explicit “Deny” effect to perform a set of actions on a set of resources to a given principal(s).
• Identity based policies: It is a permission policy document associated with a physical (user, group or role).
• Resource based policies: It is a permission policy document associated with an AWS service such as the bucket policies document in Amazon S3.
• Permission boundaries: It is a permission policy document used to define the boundaries that limit the user or role permissions. The resulting permissions are the intersection of the user associated permissions and the associated permission boundaries.
• Organizations Service Control Policies - SCPs: AWS Organizations is a service that enables central management of multiple AWS accounts, SCP is a permission policy that provides a central way to define permission boundaries on the AWS account level.
• Role Session: It is an instantiation of an IAM role that temporarily grants access to an AWS Account.
• Session Principal: It is a way that enables a user to temporarily access an AWS account by either assuming an IAM role or using an external federated identity.?
• Session Policy: It is a policy document that can be dynamically passed when assuming an IAM role and that serves as an additional layer of access control.

In the next section, we will describe the AWS policy evaluation logic:?

• One important principle when granting permissions is called the least privileges, which ensures that each user is only authorized to do actions required to perform his functions. In accordance with this principle, AWS applies a default deny to ensure nothing is granted unless it is explicitly allowed.??
• When a user sends a request to an AWS account to perform an action, AWS starts by checking if there is an explicit deny within all permission policies. In case one is specified, the final decision will be an explicit denial.

• When no explicit denial is specified, AWS will verify whether the AWS account is managed by AWS organizations service. In this case it will verify the presence of SCP documents and apply the following rule:?

If an SCP is present:

----If an Allow effect is present:

--------Move to the next step

----Else: Final decision is a deny

Else: Move to the next step        

• In case the previous step doesn’t led to a final decision, AWS will prioritize the evaluation of resource based policies and apply the following rule:

If a resource based policy is associated with the destination resource:

----If an Allow effect is present:

--------Return the final decision: Allow

----Else: Move to the next step

Else: Move to the next step:        

• In case the previous step doesn’t led to a final decision, AWS will prioritize the principal associated identity based policies and apply the following rule:

If the principal uses an identity based policy:

----If an Allow effect is present:

--------Move to the next step

----Else: return final decision: Implicit deny

Else: return final decision: Implicit deny        

• In case the previous step doesn’t led to a final decision, AWS will prioritize the evaluation of permission boundaries and apply the following rule:

If the principal has an associated permission boundaries:

----If an Allow effect is present:

--------Move to the next step

----Else: return final decision: Implicit Deny

Else: Move to the next step:        

• In case the previous step doesn’t led to a final decision, AWS will finally check if the principal is a session principal and apply the following rule:

If the principal is a session principal:

----If a session policy is present:

--------If an allow effect is present:

------------Return final decision: Allow

--------Else: Return final decision: implicit deny

----Else:

--------If this is a role session:

------------Return final decision: Allow

--------Else: Return final decision: implicit deny

Else: Return final decision: Allow:        

In conclusion, as we have seen, there is no one place to define permissions, when you have defined an “allow” effect in your associated policy documents but still facing a deny error message, you need to detect at which stage in the evaluation logic the allowance is overwritten with an implicit deny and fix it as convenient.?

Finally, to best understand the whole flow and make it easier, I highly recommend drawing it yourself and get the logic behind prioritizing a step over another.

--

Hamza EL RHAZI

Solutions Architect