5.1 Identity and access management

What this is and why it exists

Identity is the real perimeter. Network rules decide which packets may arrive; identity decides who may do what once they have. Every cloud has one system at its centre that answers the question "is this caller allowed to perform this action on this resource" — Amazon's IAM with Identity Center, Azure's Entra ID with role-based access control, Google's Cloud IAM — and learning it once is learning all three, because they answer the same question with the same four pieces.

The vocabulary

• Identity (principal) — the thing making a request: a person, an application, a machine, or another service.
• Group — a set of people that permissions are attached to, so joining the group grants them.
• Role — a set of permissions something can assume temporarily, rather than hold permanently.
• Policy — the document that actually states what is allowed or refused, on which resources, under which conditions.
• Least privilege — the permissions the job needs, and none of the ones it does not.
• Deny by default — nothing is permitted unless something explicitly permits it.
• Long-lived key — a credential that works until somebody removes it, which is the thing this topic exists to eliminate.
• Permission boundary (or guardrail) — an upper limit on what any policy inside it can grant.

The mental model

Four pieces, in one sentence: a policy says that an identity may take an action on a resource, sometimes only under a condition. Everything else is arrangement. Attach permissions to groups rather than to people, so that a new joiner gets the right access by being put in the right group and a leaver loses it by being removed from one. Attach roles to workloads rather than keys, so an application's access follows what it is rather than what it holds.

Deny by default is the property that makes the whole thing tractable. Nothing is permitted until a policy permits it, and an explicit refusal beats any permission — which means a guardrail written once at the top of an organisation cannot be undone by someone's generous policy further down. That is the mechanism behind organisation-wide rules like "no resources outside these regions" or "nobody may turn off the audit log", and it is worth setting up early, when there is little to break.

Least privilege in practice is not a heroic act of foresight, it is a loop. Start from nothing. Grant the specific permissions the task fails without. Run the task, read the denial, add exactly the permission it names, and repeat. It takes a few minutes and produces a policy that describes the job honestly. The temptation at every step is the wildcard — allow everything on everything, promise to tighten it later — and the reason to resist is not purity: an over-broad role is how one compromised component becomes a compromised account, and "later" is a promise nobody has ever kept in a hurry.

Then the piece that removes an entire class of incidents: roles for machines instead of keys. A long-lived access key is a string that grants access until somebody notices and removes it, and it ends up in repositories, in build logs, in screenshots, in a message to a colleague. The alternative is that the workload assumes a role and receives short-lived credentials automatically — from the instance's own identity, from the container platform, or through a federated identity for a build pipeline — and those credentials expire on their own, are never written down, and rotate without anybody remembering to. If you make one change to an account after this lesson, make it finding the long-lived keys and replacing them with roles.

Finally, reading a permission denial, because you will read many. A denial tells you three things — which identity, which action, which resource — and the fix is to add exactly that action on exactly that resource. The wrong fixes are the two everybody tries first: widening the policy to all actions, which makes the error go away and the audit worse, and adding a permission the message did not ask for, which usually means the request is being made by a different identity than you think. Read the identity in the message first; a surprising amount of the time it is the role of a service acting on your behalf rather than you.

What you should now be able to explain or do

State the four pieces of an authorisation decision. Say why permissions attach to groups and roles rather than to people and keys. Explain what deny-by-default makes possible at an organisation level. Build a least-privilege policy by the read-the-denial loop, and say why the wildcard is a trap rather than a shortcut. Explain how a workload gets credentials without holding a key. Read a denial and name the three facts in it.

Check yourself