AWS IAM Policies PART 4 : IAM Evaluation Logic

The AWS IAM policy evaluation logic is the process AWS uses to determine whether a user or service is allowed to perform a specific action on a resource. When a user or service (also known as a principal) sends a request to AWS, IAM evaluates the policies attached to the principal and the resource to decide whether to allow or deny the request.

AWS evaluates the request using a series of steps, following a predefined logic to determine whether the action is allowed or denied. The steps consider identity-based policies, resource-based policies, IAM permissions boundaries, and service control policies (SCPs) for AWS Organizations.

AWS Policy Evaluation Logic Steps

Here’s an overview of how the evaluation process works with examples for each step.

Step 1: By Default, Deny All Requests

By default, all requests are implicitly denied. This means that unless there is an explicit Allow in the policies, AWS automatically denies the request.

Example:
A new user, John, is created in AWS, but no policies are attached. If John tries to access any AWS service, such as S3 or EC2, the action will be denied because there are no policies allowing access.

Response: Denied (Implicitly).

Step 2: Evaluate Explicit Denies

After the default implicit deny, AWS looks for any explicit deny statements in the applicable policies. If an explicit deny is found, the request is denied immediately, regardless of any allow permissions in other policies.

Example:
Suppose John has the following policy attached to his IAM user:

Even if another policy allows John to list S3 buckets, the request is denied due to the explicit deny.

Step 3: Evaluate Explicit Allows

If no explicit deny is found, AWS evaluates whether there is an explicit allow for the requested action in any of the applicable policies. The explicit allow is needed for the action to be approved.

Example:
John has the following allow policy:

If John tries to list the objects in the example-bucket, this action is allowed since there is an explicit allow in the policy.

Response: Allowed (Explicit Allow).

Step 4: Check Resource-Based Policies

In addition to identity-based policies, AWS also checks resource-based policies if the resource supports them (e.g., S3 buckets, Lambda functions, SNS topics). Resource-based policies allow you to attach permissions directly to the resource.

Example:
Suppose John’s IAM user has no policy allowing access to an S3 bucket, but the S3 bucket has a resource-based policy allowing John’s user to list its contents:

In this case, John is allowed to list the objects in example-bucket because of the resource-based policy attached to the bucket.

Step 5: Evaluate Service Control Policies (SCPs)

If your AWS account is part of an AWS Organization, AWS also evaluates Service Control Policies (SCPs). SCPs are used to enforce or restrict permissions across an entire AWS Organization or individual Organizational Units (OUs).

SCPs don’t grant permissions but set boundaries on what permissions can be allowed by identity-based policies. Even if a user’s IAM policies allow an action, the SCP can restrict it.

Example:
If the organization has an SCP that explicitly denies access to EC2, even if John has an IAM policy that allows EC2 actions, the request will be denied.

If John tries to list EC2 instances:

Response: Denied (via SCP).

Step 6: Check Permissions Boundaries (Optional)

If a permissions boundary is attached to a user or role, AWS evaluates whether the requested action is within the boundary. Permissions boundaries are used to define the maximum allowed permissions for a user or role.

Even if the user’s policy allows the action, it will be denied if the permissions boundary does not allow it.

Example:
John has an IAM policy allowing him to create S3 buckets:

However, if a permissions boundary is attached to John that restricts S3 bucket creation, his request will be denied:

Response: Denied (Permissions Boundary).

Step 7: Session Policies (Optional)

If the request is made through temporary credentials (such as from AWS STS), any session policies attached to the session are also evaluated. These session policies further limit what can be done with the temporary credentials.

Example:
John assumes a role that has a session policy restricting access to S3. Even though his regular user policy allows access to S3, the session policy denies it:

When John tries to list S3 buckets during his session:

Response: Denied (Session Policy).

Summary of Evaluation Logic Flow:

1. Implicit Deny: By default, all actions are denied.

2. Explicit Deny: Any explicit deny in identity-based or resource-based policies immediately results in denial of the request.

3. Explicit Allow: If there’s no explicit deny, AWS checks for an explicit allow in identity or resource policies.

4. Resource-Based Policies: Resource-based policies can allow access even if no identity-based policy allows it.

5. Service Control Policies (SCPs): SCPs in AWS Organizations can limit actions regardless of the user’s identity or resource-based policies.

6. Permissions Boundaries: If present, they restrict the maximum permissions a user or role can have.

7. Session Policies: Temporary credentials with session policies can restrict the permissions during that session.

Summary of Precedence Between Policies:

1. Explicit Deny (from any policy type) always wins. If there’s an explicit deny in any policy, the request is denied.

2. Service Control Policies (SCPs) restrict what actions can be allowed in an account or organizational unit. SCPs apply across the entire organization and can block actions allowed by identity-based policies, resource-based policies, or session policies.

3. Permissions Boundaries restrict the maximum permissions for a user or role. Actions not allowed by both the identity-based policy and the permissions boundary are denied.

4. Identity-Based Policies (IAM user and role policies) grant or deny access based on the specific actions and resources defined in the policy, but they are limited by SCPs, permissions boundaries, and session policies.

5. Resource-Based Policies can grant access to resources even if the identity-based policy doesn’t allow it. However, they cannot override an explicit deny, SCP, or permissions boundary.

6. Session Policies (temporary credentials) limit what actions can be performed during a session, and they are subject to the same rules as identity-based policies.