Course page
AWS IAM in practice: least privilege without the guesswork Preview
Log in

You are watching a free preview. Enroll to open all 24 lessons, track progress and ask the course tutor.

Enroll for $49.99

Section 1: How AWS decides: the evaluation model

Anatomy of a request

Video 9 min Lesson 1 of 24 Sample clip Preview

Every action in AWS, whether a click in the console, a CLI command or an SDK call from a Lambda function, becomes an API request. IAM evaluates each request using its context:

  • Principal: who is asking. A role session, an IAM user, the root user, or an AWS service.
  • Action: what they want to do, such as s3:GetObject or ec2:TerminateInstances.
  • Resource: what they want to do it to, identified by an ARN.
  • Conditions: everything else known about the request: source IP, whether MFA was used, tags on the principal and resource, the time, the VPC endpoint it came through, and more.

Policy types that can apply

Several kinds of policy may be relevant to one request:

  1. Identity based policies attached to the user, group or role.
  2. Resource based policies attached to the resource, such as an S3 bucket policy or a KMS key policy.
  3. Permission boundaries, which cap what an identity policy can grant.
  4. Session policies, passed when assuming a role to narrow that session.
  5. Service control policies (SCPs) and resource control policies (RCPs) from AWS Organizations, which set the maximum permissions for accounts.

The core rules

  • Everything starts implicitly denied.
  • An explicit Deny in any applicable policy ends the evaluation: denied.
  • Organisation policies, boundaries and session policies act as filters. If they do not allow the action, it is denied, no matter what the identity policy says.
  • Within one account, an Allow in either the identity policy or the resource policy is generally enough, once the filters pass.
  • For cross account access, both sides must allow: the identity policy in the caller's account and the resource policy in the resource's account.

Why this matters

Most confusing access problems come from forgetting one of these layers. A developer adds s3:* to their role and still gets AccessDenied, because an SCP blocks the Region, or the bucket policy has an explicit deny for requests that do not use TLS. When you debug, walk through every layer in order rather than adding more permissions until it works.

In the next lesson we read real policies statement by statement, including the parts people usually skip.

← → switch lessons