P56 · IAM & Authorization
RBAC/ABAC, policy, least privilege, cloud IAM
Deciding what you may do: access models (RBAC/ABAC/ReBAC), policy-as-code evaluation with explicit-deny precedence and least privilege, and cloud IAM done safely.
Authentication finishes; authorization never does. Every request after the login
carries an implicit question — is this caller allowed to do this, to this
object, right now — and unlike identity, the answer cannot be cached in a
session and forgotten. This pillar is about answering it deliberately, with a
model you chose, rather than accidentally, with an if statement someone added
under deadline.
It starts with the three models you will actually meet. RBAC assigns permissions to roles, which is simple and drifts into role explosion. ABAC decides on attributes of the subject, resource and context, which is expressive and harder to audit. ReBAC decides on relationships — is this user the owner of that document — which is what most products mean when they say "sharing". Under all three sits deny by default, and against all three sits the confused deputy: a privileged component doing something on behalf of a caller who could not have done it directly, which is the shape of a surprising number of real bugs and, later in P59, of an over-permissioned agent. The pillar then makes policy concrete: evaluating IAM-style documents where wildcards match more than their author expected and an explicit deny must beat any allow, and reducing an over-broad grant to the permissions actually needed. It ends in the cloud, where this is daily work — principals and service accounts, temporary credentials against long-lived keys, trust policies, and finding the over-grant in a role someone wrote in a hurry — and closes with the capstone that ties P54, P55 and P56 into one authorization decision that holds.