Least privilege by design
Classify access by risk, grant narrow and auditable permissions, and make denials easy to diagnose.
Access is a design decision
Building Secure and Reliable Systems argues that least privilege has to be designed in. Retrofitting it to a system where everyone has root rarely works. The chapter's first step is to classify access by risk. Reading public metrics is low risk. Deploying a service, reading customer data, or changing access control is high risk. Each class gets proportionate controls:
| Risk | Example | Reasonable control |
|---|---|---|
| Low | Read dashboards | Authenticated, broadly granted |
| Medium | Restart a service, deploy a reviewed artifact | Role-based, audited, via a narrow tool |
| High | Read customer PII, change IAM, delete data | Multi-party approval, time-bound, justified, alerting |
The same thinking applies to machine identities. A deploy bot, a CI runner, and a monitoring agent each get a role scoped to what they do. Shared "admin" identities do not survive this classification.
Small interfaces beat big hammers
The book prefers small functional APIs over general access. If on-call engineers need to restart Waybill, give them a tool or API that restarts Waybill, not an interactive root shell on every host. A narrow interface:
- exposes only intended actions,
- can be audited meaningfully, since the logs say "restart waybill by sal" and not a list of shell keystrokes,
- can enforce policy (rate limits, approvals) in one place,
- and limits damage from mistakes and compromised accounts.
Kubernetes RBAC, sudo rules for specific commands, and deployment pipelines that hold the only production credentials all apply the idea.
Advanced controls
For high-risk actions the book describes several controls:
- Multi-party authorisation: a second person approves the action. It stops both insiders and single compromised accounts.
- Temporary access: grants that expire automatically, requested with a business justification.
- Proxies: privileged actions go through an audited proxy instead of direct credentials.
- Break-glass: an emergency bypass that is always available, always logged, alerts security when used, and is reviewed afterwards. It must exist, because outages happen when normal paths are broken. It must be loud, so it does not become the normal path.
Make denials diagnosable
Least privilege fails socially when denials are mysterious. Engineers then lobby for broad roles "to be safe". The book recommends making denial messages say who was denied what on which resource and how to request access. Kubernetes does this well ("User system:serviceaccount:ci:deploy-bot cannot patch resource deployments in API group apps in the namespace waybill"). That message is a complete specification of the missing permission.
The operator's discipline is to read the denial, grant exactly that, and record why. The tempting alternative, binding cluster-admin or running chmod 777 "temporarily", turns the next incident into a security incident.
Least privilege also protects against mistakes
Most damage from excessive access is not malicious. A script run against the wrong environment, a command typed on the wrong host, or an automation bug with admin credentials can all destroy as thoroughly as an attacker. BSRS stresses this overlap between security and reliability. Narrow, scoped access shrinks the blast radius of every kind of error.
Key terms
- Least privilege
- Every identity, human or machine, has only the access its current task requires, for only as long as needed.
- Break-glass
- An emergency path that bypasses normal controls. It is tightly audited and triggers alerts and review whenever used.
- Multi-party authorisation
- A sensitive action requires approval from a second person before it runs.
- Blast radius
- How much can be damaged if one identity or component is compromised or misused.
Read further
- Building Secure and Reliable Systems, Ch. 5, "Design for Least Privilege" (Free to read online)
Classifying access by risk, small functional APIs, breakglass mechanisms, auditing, and the advanced controls (multi-party authorisation, temporary access, proxies). Also read the section on diagnosing access denials. - Building Secure and Reliable Systems, Ch. 2, "Understanding Adversaries" (Free to read online)
Attacker motivations and profiles, including insiders. Note why least privilege also limits honest mistakes. - Container Security, Chapter "Container Security Threats" (Purchase)
The threat model for containerised systems and the security principles at the end, especially least privilege and defence in depth.