Least privilege is widely agreed with and rarely implemented, because the ideal version is genuinely hard. The practical version is not: group permissions by role, start narrow, widen when something is blocked, and review occasionally.
Structure permissions around roles
Attaching permissions to individuals produces a permission set nobody can audit within a year. Define a handful of roles that match how people actually work, attach policies to those, and put people in them.
-
Administrator
A small named group. Can change identity and account configuration.
-
Engineer
Creates and manages workload resources. Cannot alter identity or billing.
-
Read-only
Can see everything, change nothing. The right default for most people.
-
Automation
Machine identities scoped to one pipeline or job. No console access.
Build it in the right order
- Start every human in read-only.
- Add the engineer role for people who need to create resources.
- Keep the administrator group to as few people as the work allows.
- Give each automated process its own identity, never a shared one.
- Prefer temporary elevation over standing administrative access.
- Review membership quarterly and remove what is unused.
Scope machine identities tightly
Automation is where over-permissioning hides, because it is invisible and nobody complains. A deployment pipeline usually needs to update one service, read from one registry and write to one bucket. It rarely needs to delete networks.
| Dimension | Narrow it by |
|---|---|
| Action | Only the operations the job performs. |
| Resource | Only the specific resources, by name or prefix. |
| Environment | A separate identity per environment. |
| Time | Short-lived credentials where the platform supports them. |
| Source | Conditions on the calling identity or workload where available. |
Make it observable
Least privilege only stays true if you can see it drifting. Alert on new administrative identities, on policy changes, and on any use of the root identity. Those three alerts catch most of the ways a careful setup quietly degrades.
Summary
Roles not individuals, read-only by default, one identity per automated job, explicit denies for the unthinkable, and alerts on privilege changes. That is achievable in an afternoon and removes most of the practical risk.
