Identity is the new perimeter
In the old world, security was a wall: a corporate firewall around the office, and everything inside was trusted. In the cloud that wall is gone. A leaked key works from a coffee shop in any country; there is no "inside." What replaces the wall is identity — who is making this request, and what are they allowed to do? This is why people say "identity is the new perimeter." Chapter 2 introduced IAM and least privilege; this lesson goes deep enough to actually reason about a real-world policy: how requests are evaluated, the difference between roles and policies, the access-control models, the guardrails that cap blast radius, and the sneaky paths attackers use to escalate from a small foothold to full control.
On-ramp in one breath: every cloud action passes one gate — "is this identity allowed to do this thing to this resource?" Master how that gate evaluates, and you can both grant access safely and spot the holes attackers walk through.
The vocabulary, defined once
- Identity — an authenticated actor. A user is a human; a role / service account is a machine identity (Ch. 2). A group is a bag of users you attach permissions to once.
- Policy — a document (usually JSON) that grants or denies a set of (action, resource) pairs, optionally under conditions. Policies are the rules; identities are the actors. Roles are not policies — a role is an identity you attach policies to.
- Least privilege — grant the minimum permissions an identity needs, no more (Ch. 2). The governing principle of everything below.
- CIEM — Cloud Infrastructure Entitlement Management: tooling that finds over-permissioned identities (who can do what they never actually use) and helps you trim them.
How a request is actually evaluated
This is the part most guides skip — and it's where real reasoning lives. When an identity makes a request, the cloud evaluates all applicable policies and reaches an allow/deny decision by a fixed order of precedence. The durable rule across the major clouds:
Three durable rules fall out of that diagram:
- Default deny. If nothing explicitly allows an action, it is denied. Permissions are opt-in.
- Explicit deny always wins. A
Denyoverrides anyAllow, no matter how broad. This is how you carve hard exceptions ("nobody, ever, may delete the audit logs"). - A request must pass every policy type in scope — the identity's own policy, and any boundary/guardrail on top (next section). It only takes one "no" to deny.
:::tip Trace it like a checklist To predict whether a request succeeds, walk the diagram literally: (1) is there a matching explicit deny? If yes → denied, stop. (2) Is there a matching allow? If no → denied (default). (3) Does a permission boundary or org guardrail also allow it? If no → denied. Only if all three clear does the action go through. Most "why can't my app do X?" tickets are solved by this trace. :::
Roles vs policies (the distinction that confuses everyone)
A policy is a rule; a role is an identity that wears rules. You don't "give someone a policy" so much as you attach a policy to a role (or user/group), and then an actor assumes the role to act with its permissions. Why machines should use roles, not embedded keys, was Chapter 2's lesson — and 8.3 takes it further to keyless auth. The mental model:
Identities (users, roles) assume permissions; policies define those permissions; attaching a policy to an identity is how a permission becomes real.
RBAC vs ABAC: two ways to decide
There are two durable models for how you express who-gets-what:
- RBAC — Role-Based Access Control. Permissions are bundled into roles ("billing-reader," "deploy-admin") and you assign identities to roles. Simple, auditable, and the default in Kubernetes and most orgs. Downside: role explosion — you can end up with thousands of fine-grained roles.
- ABAC — Attribute-Based Access Control. Access is decided by attributes/tags evaluated at request time: "allow if the resource's
teamtag equals the user'steamattribute." One rule scales to many teams without new roles. More powerful, harder to audit, and easy to get subtly wrong.
Most real systems are RBAC with a dash of ABAC (tag-based conditions on top of roles). Neither is "better" — RBAC for clarity, ABAC for scale.
Permission boundaries & guardrails: capping the blast radius
Least privilege says "grant little." But humans grant too much, and delegated admins grant even more. A permission boundary is a ceiling: a policy that defines the maximum an identity can ever have, regardless of what permissions someone later attaches to it. Even if a teammate attaches AdministratorAccess, the boundary still caps the effective permissions to its intersection.
The same idea at the organization level is a guardrail (e.g. AWS Service Control Policies / Azure Policy / GCP Org Policy): an org-wide rule that no account can exceed — "no resource may be created outside the EU," "root user may never be used." Boundaries protect against individual over-granting; guardrails protect against whole accounts drifting. Both turn least privilege from a hope into an enforced ceiling.
Just-enough and just-in-time access
Two refinements that cut standing risk:
- Just-Enough Access (JEA) — the scope refinement of least privilege: not "admin," but exactly the actions needed.
- Just-In-Time Access (JIT) — the time refinement: instead of standing permanent access, an engineer requests elevated access for a window (say 30 minutes), it's granted (often with approval), and it auto-expires. Standing admin access is a permanent target; JIT means the dangerous permission exists only while it's being used. Short-lived in time mirrors the short-lived credentials of 8.3.
Privilege-escalation paths and CIEM
The subtle danger: an identity with seemingly modest permissions can sometimes escalate to full control through a chain. Classic examples:
- Permission to modify an IAM policy → grant yourself admin.
- Permission to assume a more powerful role → become it.
- Permission to launch compute that has a powerful role attached, then use that compute's credentials → inherit the powerful role.
- Permission to update a function's code that runs with a powerful role → run arbitrary code as that role.
None of these looks like "admin" on paper, yet each is a path to it. Finding these chains by hand across thousands of identities is hopeless — which is why CIEM tooling exists: it maps every identity's effective, transitive reach (including escalation paths), flags the over-permissioned and unused entitlements, and recommends trims. CIEM is one pillar of the CNAPP consolidation you'll meet in 8.7.
Why it matters
In the cloud there is no trusted "inside" — identity is the perimeter, and IAM is the gate every request passes. Reason about that gate precisely: default deny, explicit deny wins, and a request must clear every policy and boundary in scope. Distinguish roles (identities) from policies (rules); pick RBAC for clarity and ABAC for scale; cap blast radius with permission boundaries (per-identity ceilings) and org guardrails (account-wide ceilings); shrink standing risk with just-enough and just-in-time access; and use CIEM to hunt the over-permissioned roles and privilege-escalation paths you'll never find by eye. Over-permissioned identity is the leading cause of cloud breaches — this is the lesson most worth re-reading.
Common pitfalls
- Granting
*"to make it work." A wildcard that ships to prod is a standing breach. Start from zero and add the specific actions the logs show you actually need. - Confusing a role with a policy. You attach policies to roles; assuming a role is itself "the permission" leads to muddled, over-broad grants.
- Ignoring escalation paths. "This role can only edit IAM" sounds limited — but editing IAM is a path to admin. Audit for transitive reach, not just direct actions.
- Permanent admin for humans. Standing admin is a perpetual target. Prefer JIT elevation that expires.
- No boundary or guardrail. Without a ceiling, one over-eager grant uncaps an identity. Boundaries and org guardrails make least privilege enforceable, not aspirational.
Where this connects
- Back to Chapter 2 · IAM — this lesson is that primitive, deepened to real policy reasoning.
- Forward to 8.3 Workload identity & keyless auth — applying identity to machines without any long-lived secret.
- Across to the Modern Security Engineer Guide — for authentication protocols and identity theory beyond the cloud-ops view.