How AWS IAM Handles Conflicting IAM Policies

Overview

When a user attempts an action in AWS, such as launching an EC2 instance or listing S3 buckets, AWS evaluates all involved IAM policies to determine whether to grant the request. Since IAM policies can be associated with various types of identities, the hierarchy of these identities influences the final permissions for a user.

AWS IAM Policy Evaluation Flow

Let’s break down the process of how AWS evaluates a request using the simplified version of the AWS flow chart below:

1. Default Deny

AWS denies a request by default. For example, if your IAM user has no policies attached and you attempt to read an S3 object, your request is implicitly denied.

2. Explicit Deny

If there’s an explicit DENY in any of the policies involved in the request, IAM denies the request.

3. AWS Organizations’ Service control policies (SCPs)

When a request is made in an AWS account with Organizations’ SCPs in place, IAM first examines the SCPs to determine if the action is allowed. If the SCPs don’t allow the action, IAM denies the request.

4. Resource Policy Evaluation

If there’s no SCP to evaluate or there are no conflicts in the SCP, IAM proceeds to check the resource policy. Keep in mind that not all AWS services have a resource policy. Examples of services with resource policies include the S3 bucket policy, KMS key policy, Lambda function resource policy, and SQS queue policy. You may refer to this page to see which services support resource-based policies.

5. Identity-based Policy Evaluation

IAM then checks the policies attached to the IAM user or role making the request. If no policy matches the requested actions, the request is denied. IAM also implicitly denies the request if no identity-based policies are present.

6. Permissions Boundary

IAM checks whether any statements in the permissions boundary would prevent the requested action. If there is, the request is denied. Otherwise, the evaluation process continues.

7. Session Policy Evaluation

Finally, IAM checks if the request includes a session policy. A session policy is an inline permission assigned to a session principal. Session principals are users who obtain temporary access through AWS Security Token Service (STS), such as federated users, role session users, and web identity users. If the session policy permits the action, then IAM grants the request. On the other hand, when no session policies are involved, IAM determines whether the principal is a role session, and if so, allows the request.

Same-Account vs. Cross-Account Access

It’s important to understand that the policy evaluation for same-account access differs from cross-account access. The diagram above depicts the policy evaluation for cross-account access.

In the same-account access setting, permissions can be granted either through the resource policy or the identity policy. For instance, even if an IAM user has no policies assigned, they can still be granted access to an S3 bucket if authorized in the bucket policy. In a similar manner, an S3 bucket without a bucket policy can be accessed by an IAM user, provided their identity policy permits such access. Take note that this logic does not extend to the IAM role trust policy and KMS key policy. For these two resource policies, permissions must be explicitly granted within the identity policies of the principal.