Policy Evaluation Logic
Learn how different policies are evaluated in AWS to allow or deny access for a resource to a principal.
We'll cover the following
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.
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 “Alice” attempts to upload a file to an S3 bucket named
example-bucket
.Resource: The S3 bucket
example-bucket
with ARNarn:aws:s3:::example-bucket
.Principal: IAM user “Alice” 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
ands3:PutObject
on the S3 bucketexample-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 “Alice” with ARNarn:aws:iam::123456789012:user/alice
.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 “Alice” 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 “Alice” 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.
Get hands-on with 1300+ tech skills courses.