← Back to Labs L2 Intermediate

AWS · Identity · Permission Boundaries

AWS Permission Boundary Basics

Intermediate LAB for understanding how AWS permission boundaries constrain maximum principal authority without granting access by themselves.

Status Intermediate
Cloud AWS
Domain Identity
Track L2

Overview

Permission boundaries define the maximum permissions an IAM principal can have. They are a critical safety mechanism for delegated administration and privilege-escalation prevention.

L2 Intermediate Policy reasoning Maximum authority No live mutation

Concept Deep Dives

Expand these concepts when studying permission boundaries or explaining delegated IAM governance.

What is a permission boundary?

A permission boundary is an IAM policy used to set the maximum permissions an identity can have. It does not grant access by itself. It only limits what identity policies can successfully allow.

How is a boundary different from an identity policy?

An identity policy grants or denies requested actions. A boundary defines the outer limit of what the identity is allowed to receive. The final decision requires both the identity policy and the boundary to permit the action.

Why does a boundary not grant access?

A boundary is a limit, not a permission source. If only the boundary allows an action but no identity policy allows it, the action is still denied.

Why does this matter for delegated administration?

Boundaries let platform teams delegate IAM creation or management while preventing delegated users from creating identities with authority above an approved ceiling.

What should executives understand?

Permission boundaries are governance guardrails. They help reduce the risk that teams accidentally or intentionally create identities with excessive authority.

Visual Boundary Model

Permission boundary reasoning is easiest when viewed as a maximum-authority decision path.

Principal User, role, workload, or delegated admin
→
Identity Policy Requests or allows an action
→
Permission Boundary Defines maximum allowed authority
→
Effective Decision Allow only if the action survives the boundary
Identity Allows The principal has an apparent allow
+
Boundary Allows The maximum-authority ceiling permits it
→
Possible Allow Unless another explicit deny applies
Identity Allows The principal has an apparent allow
+
Boundary Does Not Allow The ceiling blocks the action
→
Deny The requested authority exceeds the boundary
Learning rule: a permission boundary is a maximum-authority guardrail. It limits access; it does not grant access.

Example Scenario

A developer role has an identity policy that allows role creation, but a permission boundary prevents the developer from creating roles with administrative authority. 

Identity policy: iam:CreateRole allowed
Permission boundary: administrative role patterns not allowed
Final decision: DENY when requested authority exceeds boundary

Bridge to Principal LABs

Permission boundaries prepare learners to reason about whether advanced identity paths become exploitable escalation paths.

iam:PassRole Privilege Escalation Boundary design can limit roles that may be created or passed. Cross-Account Role Escalation Boundary reasoning helps evaluate delegated role administration safely. Role Chaining Escalation Boundaries can reduce downstream authority when attached consistently.

Governance Boundary

This lab is read-only and deterministic. 

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not exploit AWS
  • Does not mutate infrastructure
  • Does not deploy live resources
  • Does not issue runtime tokens
  • Does not override OPA

Source Artifacts

  • metadata.json
  • architecture.md
  • index.html