Policy Evaluation for AWS IAM and Resource Policy

All articles in

Identity and Access Management

Policy Evaluation for AWS IAM and Resource Policy

Policy evaluation is a complex topic in AWS since a single principal can have multiple policies applicable to it at a single point of time, and the permissions in these policies might conflict with each other causing a troubleshooting nightmare. To add to the complexity, the policy evaluation logic is different when a request is made to access resources in the same AWS account (intra-account access) vs a different AWS account (cross-account access). We will be covering policy evaluation in multiple articles and demos in order to make it easier to understand. In this article, let’s see the policy evaluation logic for cases where both IAM Policy and Resource Policy are applicable for a particular AWS Principal.

Intra-account access

For intra-account access, the total permission applicable to an AWS principal is the addition of the permissions provided in the IAM policy and Resource policy. For example, consider a user – Indiana with an IAM policy attached to it which gives the permission – “lambda:InvokeFunction” on a Lambda function. Also, the same Lambda function has a resource policy which allows user Indiana to do – “lambda:TagResource”. Then the total permission for user Indiana on that Lambda function would be – “lambda:InvokeFunction, lambda:TagResource”. Also, if there is any Deny statement in either IAM or Resource policy, it would override any Allows.

So, for intra-account access the policy evaluation follows this logic:

By default, all requests are implicitly denied. An implicit deny is applicable when there are no Allow or Deny statements in the policy. Please remember that the AWS root account is an exception here since by default it has full access. Learn more about it from AWS Users article.
An explicit allow in an IAM or resource policy overrides this default. The total permission is addition of all permissions allowed in IAM and resource policy.
An explicit deny in any policy overrides any allows.

But there is one exception to the above policy evaluation logic:

Exception – For the KMS key, the resource policy attached to the key must explicitly “delegate” permissions to the AWS IAM. Without this, even if you add KMS permissions via IAM policy to users, it would not take any effect. To see this exception in action, see the video demo at the end of this article.

Below table would make it easy for you to remember the policy logic:

Requesting Principal	Resource Policy	IAM Policy	Result	Exception	Reason
User, Role (A role itself cannot make a request. Requests are made with the role session after a role is assumed)	N/A (Implicit Deny)	N/A (Implicit Deny)	Deny	Root User (has full access by default)	By default, all requests are implicitly denied
	Allow Principal	N/A (Implicit Deny)	Allow		An explicit allow in an IAM or resource policy overrides the implicit Deny
	N/A (Implicit Deny)	Allow Principal	Allow	KMS keys
	Allow Principal	Allow Principal	Allow
	Allow Principal	Deny Principal	Deny		An explicit allow in an IAM or resource policy overrides the implicit Deny
	Deny Principal	Allow Principal	Deny

Cross-account access

Cross-account access means that a principal in one AWS account sends a request to access the resources of another AWS account. When a cross-account access request is made, the AWS policy evaluation is a little stricter than intra-account access request and for obvious reasons. AWS allows the cross-account request only when explicit allows are made in both the IAM policy (attached to the principal requesting access) and resource policy. For example, let’s say IAM User – David wants to read objects from a S3 bucket in a different AWS account. First, the admin of the account which has the S3 bucket would need to add permissions to David’s IAM user to be able to read objects from the S3 bucket via S3 bucket policy. Then David needs to give his own IAM user permissions to be able to read objects from that particular S3 bucket via IAM policy attached to the user.

Please also note that there is more than one way to solve the above use case for David. The admin for the S3 bucket AWS account could have also created an IAM role with permissions to read objects from the S3 bucket and a trust policy allowing it to be assumed by David’s IAM user from a different account. Then, the IAM policy for David’s IAM user would need to have permissions to assume the above IAM role. Note the subtle difference in this pattern from the previous one, the resource being accessed cross-account is the IAM role (not S3).

Both of the above patterns demonstrate that you need allows in both resource policy (S3 or Role) and IAM policy for cross-account access to be successful.

Warning Note → There are still some types of policies which we have not covered and which would impact the policy evaluation – SCP, Permissions Boundary and Session policy. I would introduce these gradually and we would update the evaluation logic once we have an understanding of these topics. But for now, I wanted to keep our discussion on policy evaluation at a simpler level.

Lab Demo

In the video lab walk-through, we would show the general policy evaluation logic for IAM and Resource policies, and the exceptional case of KMS policies. We would also show the cross-account policy evaluation for accessing a S3 bucket in a different AWS account.

Video walk-through on policy evaluation

Security tidbits

Summary of security best practices to keep in mind regarding Policy Evaluation for IAM and Resource Policy: