IAM policy evaluation and explicit deny

1. IAM policy evaluation and explicit deny

One distinction closed the last video, and everything downstream leans on it: AWS checks the identity your code runs as, not the person who triggered it. Now let's look at what actually gets checked.

2. A policy is a list of rules

What AWS checks about the identity is a policy: a list of statements, where a statement is one rule with four fields. Effect says allow or deny. Action says which API call. Resource says what it points at, named by an ARN, an Amazon Resource Name, the unique ID AWS gives every resource.

3. A policy is a list of rules

Condition adds requirements about the circumstances, and there can be more than one. SecureTransport requires an encrypted connection. SourceIp requires the request to come from a given network range. Read together, this statement allows one read, on one path in the reports bucket, over an encrypted connection, from one network. Four fields, one rule. That is the whole shape of a policy.

4. Three fields ask, one field answers

Here is what makes those four fields click. Three ask a question, and only one answers. Action, Resource and Condition decide whether this rule is even in play. Think of a bouncer checking your name, the venue, and the dress code before giving a yes or no. Only if all three match does Effect matter. Three fields ask. One field answers.

5. Rules come from more than one place

A single request rarely has one statement voting on it. AWS gathers every applicable statement, wherever it lives. An identity-based policy hangs off the role itself and describes what that role may do.

6. Rules come from more than one place

A resource-based policy hangs off the thing being reached, like an S3 bucket, and names which principals can reach it. Principal, from video one, is the identity making the call. Both kinds count toward the same decision.

7. When the rules disagree

So what happens when they disagree? This is the rule that catches people out. Two statements from one policy: the first allows everything across S3, the second denies one specific delete.

8. When the rules disagree

Deleting an object fails. An explicit deny always beats an allow, however many allows sit beside it, and however broad they are. It is a banned list overriding a VIP pass. One deny ends the decision.

9. The evaluation order, and implicit deny

That gives us the order. AWS looks first for an applicable explicit deny and stops there if it finds one. Only then does it look for an allow. If it finds neither, the request still fails, and that has its own name. Implicit deny means nothing denied you and nothing granted you either: a locked door nobody ever gave you a key to. It is the quieter failure, and the more common one.

10. Four requests, three outcomes

Take one policy: a broad allow across S3, and a narrow deny on one delete. A read is allowed. A delete is explicitly denied. Now a call to Key Management Service, KMS, which holds encryption keys, or to DynamoDB, Amazon's managed key-value database. This policy never mentions either service, so nothing allowed them and nothing denied them. That is implicit deny, and it is why adding a permission to the wrong policy changes nothing.

11. Why adding permissions often fails

This is why adding permissions until the error goes away doesn't work well. Both denials produce the same AccessDenied message and need different fixes. If something explicitly denies you, another allow changes nothing. If nothing allows you, the fix is one narrow allow on the identity that made the call, not a broad one bolted onto whichever policy you opened first. Next time you hit AccessDenied, ask which denial it is before you touch a policy.

12. Let's practice!

Let's practice policy evaluation and explicit deny with a few questions.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.