Cloud IAM
A track of P56 · IAM & Authorization.
Cloud IAM in practice — principals and service accounts, temporary vs long-lived credentials, trust policies, spotting over-grants, and the P54–P56 identity capstone.
A deployment fails at six in the evening with a permission error. Somebody widens the role until it works, intending to narrow it tomorrow, and tomorrow the incident is over and nobody remembers. That role now exists indefinitely, attached to a service, holding considerably more authority than the service has ever used — and it is not a hypothetical, it is the single most common finding in cloud security reviews. This track is about the practice that prevents it and the reading skill that finds it afterwards.
It starts with the vocabulary, because cloud IAM has a specific one and reasoning is impossible without it. A principal is whoever is making the request — a human user, or a service account belonging to a workload. A trust policy says who is allowed to become a principal, which is a separate question from what that principal may then do, and conflating the two is how an assume-role chain ends up wider than anyone intended. Then the credential question, where the guidance is unusually clear-cut: long-lived access keys leak, get committed, get copied into a laptop that leaves the company, whereas temporary credentials issued on demand and expiring on their own remove most of that exposure by construction.
With those in place, the track does the reading exercise that matters — inspecting a real-shaped role and spotting the over-grant, using the evaluator from the previous track rather than an impression. It then closes the pillar and the domain with the identity capstone: a single authorization decision assembled from all three pillars, where the caller is authenticated (P54), the token is verified and its claims are trusted for the right reasons (P55), and the policy is evaluated against a model with a sane default (P56). Any one of those three missing, and the decision does not hold.