Ref: https://learn.cantrill.io/courses/1820301/lectures/41301362

• Summary
• Contents:

IAM Policy

• 🔧 Document that outlines permissions to access AWS resources and executable actions
  • Written in JSON
  • ALLOWS or DENIES access to AWS resources and/or AWS operations/actions
  • 💡 You should understand the structure of IAM policies, and learn to read & write them

Policy Statements

• 🔧 IAM policies contain a list of permission/security statements
  • Can control permissions very, very granularly
• Components of a Statement
  • SID = Statement ID: human-readable description of what statement does
    • Optional, good practice to include (makes policy readable)
  • Resource: list of AWS resources in scope of statement
    • Defined by ARNs, can use * as wildcard (matches all)
    • e.g. arn:aws:s3:::catgifs/* = all objects inside the S3 bucket named catgifs
  • Action: list of operations/actions in scope of statement
    • Operations/actions defined in AWS API, can use * as wildcard (matches all)
    • e.g. s3:ListBuckets = operation that lists all buckets in the account when executed
    • e.g. s3:* = any operation that can be executed in S3
  • Effect: Allow or Deny
  • ❗ A statement can be thought of as a RULE: If Action & Resource match → apply Effect
• Example of an IAM Policy with 2 Statements

Permission Priority Criteria

• ‼️ DENY - ALLOW - DENY !!
  • 💡 Memorize this criteria, it's really important!
  • More specifically: Explicit DENY > Explicit ALLOW > Default (Implicit) DENY
    • Explicit DENY always wins
  • Solves statement overlaps/conflicts
• ❗ Implicit Deny: all identities are, by default, denied access to resources!
  • In order to be able to access a resource or execute an action, an identity must be explicitly granted/allowed access to that resource/action, AND there must be no explicit DENY overriding this explicit ALLOW!
  • ‼️ EXCEPTION: the root user can't be restricted, and has access to all AWS resources and actions in the account!
    • 💡 Exception to this exception: Service Control Policies (SCPs) can restrict the root user, since SCPs apply to the whole account!
• Applying Permission Priority Criteria to previous Example:

IAM Policy Types

Attachment Types: Identity Policies vs Resource Policies

• IAM Identity Policies: can get attached to AWS identities (IAM users, groups or roles)
  • Identity-level permissions, permissions from perspective of identity
  • Can be inline or managed (see below)
  • AWS knows which policies an (authenticated) identity has → AWS knows all the statements that apply to the identity based on the attached policies
• IAM Resource Policies: attached to AWS resources
  • e.g. S3 bucket policy, SNS topic policy…
  • Resource-level permissions, permissions from perspective of resource
  • Must specify “Principal” in their statements → indicates to which identities (internal or external) the statements apply to
    • ❗ Unlike identity policies, resource policies can allow/deny cross-account identities, anonymous Principals (external to AWS) and even unauthenticated Principals!
  • More info in this lecture/section: S3 Security (Bucket Policies & ACLs)