Policy Evaluation Logic

Policy Evaluation Logic

In this tutorial, we are going to explore about the Policy Evaluation Logic and how different policies are evaluated in AWS to allow or deny access for a resource to a principal.

AWS Policy Evaluation Logic is the process by which AWS determines whether a request to access a resource should be allowed or denied. AWS evaluates multiple policy types—such as IAM policies, resource-based policies, permissions boundaries, service control policies (SCPs), and session policies

Policy evaluation is a critical aspect of managing access to resources within the Amazon Web Services (AWS) environment. AWS employs a sophisticated policy evaluation process to determine whether to allow or deny requests for accessing resources based on the permissions defined in policies.

How policy evaluation works

The evaluation process begins with the request context, which includes information about the actions requested, the AWS resource involved, details about the principal making the request (such as associated policies), environmental data, and resource-specific data.

AWS evaluates policies in a specific order, starting with identity-based policies and progressing through resource-based policies, IAM permissions boundaries, and other policy types. An explicit deny in any policy overrides an allow.

Let’s look at the common rules for the policy evaluation:

  • Allow vs. deny: If at least one policy explicitly allows the requested action and no policy explicitly denies it, the request is allowed. However, if any policy explicitly denies the action, the request is denied, regardless of any other policies that might allow it.
  • Implicit deny: If no policy explicitly allows the requested action, the default behavior is an implicit deny, meaning the request is denied by default. IAM principals must be explicitly allowed to perform actions.
  • Impact of policy types: Each policy type has its own rules for evaluation and can affect the final decision. For example, IAM permissions boundaries set the maximum permissions that an identity-based policy can grant, while AWS Organizations SCPs specify the maximum permissions for an organization or organizational unit. The diagram below depicts the flow in which a policy is evaluated.
Policy Evaluation Logic
Case study

Consider a scenario where an organization has deployed various resources on AWS, including Amazon S3 buckets, EC2 instances, and RDS databases. The organization follows the best practice of implementing granular access control using IAM policies to ensure that only authorized users can access specific resources.

Let’s start by looking at the request context:

  • Action: An IAM user named “Ashok” attempts to upload a file to an S3 bucket named example-bucket.
  • Resource: The S3 bucket example-bucket with ARN arn:aws:s3:::example-bucket.
  • Principal: IAM user “Ashok” with associated policies.
  • Environment data: The request originates from a trusted IP address within the organization’s network.
Policy evaluation

The policy evaluation will follow the following logic here:

  • Identity-based policy: This policy allows actions s3:GetObject and s3:PutObject on the S3 bucket example-bucket.
    • Evaluation: The policy explicitly allows the s3:PutObject action, so the request is permitted.
  • Resource-based policy: This policy allows s3:PutObject action for the IAM user “Ashok” with ARN arn:aws:iam::123456789012:user/ashok.
    • Evaluation: The policy explicitly allows the s3:PutObject action for the specified IAM user, confirming the request’s validity.
  • IAM permissions boundary: No permissions boundary is set for the IAM user “Ashok” in this scenario.
  • AWS Organizations SCPs: No SCPs apply to the request in this scenario.
  • Session Policies: No session policies are applied to the request.

Based on the evaluation of identity-based and resource-based policies, the request made by IAM user “Ashok” to upload a file to the S3 bucket example-bucket is allowed. The policy evaluation process ensures that only authorized actions are permitted, maintaining the security and integrity of the organization’s AWS resources.

Key Steps in AWS Policy Evaluation Logic

1. Default Deny

  • By default, AWS denies all requests. This implicit deny is the starting point.
  • If no policy explicitly allows an action, the request is denied.

2. Evaluate Explicit Denies

  • AWS checks for any explicit deny statements. An explicit deny always overrides any allows, regardless of other policies.
  • If any policy contains a deny for the requested action, the request is denied immediately.

3. Evaluate Explicit Allows

  • If no explicit denies are found, AWS looks for explicit allow statements in applicable policies.
  • If an explicit allow exists, the request is allowed unless restricted by another policy.

4. Policy Types in Order of Evaluation

  • AWS evaluates various policy types in a specific order, as they all contribute to the overall decision:
    • IAM Policies (Identity Policies): Attached to users, groups, or roles and define which actions they can perform on specific resources.
    • Resource-Based Policies: Policies attached to resources like S3 buckets, SQS queues, and KMS keys, specifying who can access the resource and what actions are allowed.
    • Permissions Boundaries: Define the maximum permissions an IAM user or role can have. They act as a limit, so even if a user or role policy allows an action, the permissions boundary can restrict it.
    • Service Control Policies (SCPs): Used with AWS Organizations to define maximum permissions across all accounts within an organization or organizational unit (OU). SCPs act as permission ceilings, overriding individual IAM policies within the accounts.
    • Session Policies: Temporary policies associated with a session when assuming a role. They further limit permissions for that session, regardless of permissions granted by IAM or resource-based policies.

5. Conditions

  • AWS evaluates policy conditions at each step. Conditions are specific requirements (such as IP address, time of day, or presence of multi-factor authentication) that must be met for a policy to apply.
  • If conditions in a policy are not met, the policy will not apply, regardless of any allow or deny statements it contains.
    Final Decision Process
    1. Deny If No Explicit Allow:
      • If there’s no explicit allow found across any of the evaluated policies, the request is denied by default.
    2. Allow Only If No Explicit Deny:
      • If an explicit allow exists and no explicit deny blocks the action, the request is allowed.
    Policy Evaluation Summary
    1. Explicit Deny > Explicit Allow: Explicit denies always take precedence.
    2. Permission Boundaries and SCPs Set Maximum Permissions: These act as upper limits, restricting IAM policies and resource-based permissions.
    3. Implicit Deny (Default): Anything not explicitly allowed is implicitly denied.
    AWS Policy Evaluation Logic Best Practices
    1. Use Explicit Denies for Critical Actions: Denying high-risk actions (e.g., deleting resources) at the SCP or permissions boundary level adds a layer of protection.
    2. Least Privilege Principle: Grant only the minimum permissions needed, helping reduce the risk of unintended access.
    3. Use Conditions for Fine-Grained Access Control: Use conditions to enforce policies based on factors like source IP, MFA, or request time, adding further control.
    4. Test Policies with IAM Access Analyzer: AWS IAM Access Analyzer helps test and validate policies, showing effective permissions and detecting overly permissive policies.

    By following the policy evaluation logic, AWS ensures that policies are evaluated in a consistent, secure, and predictable manner, making it easier for users to manage permissions while maintaining tight security.

    That’s all about the AWS policy evaluation. If you have any queries or feedback, please write us at contact@waytoeasylearn.com. Enjoy learning, Enjoy AWS Tutorials.!!

    Policy Evaluation Logic
    Scroll to top