Least privilege explained

Topic: Security basics

Least privilege means granting only the minimum permissions needed for a task. Apply it to users, services, and roles to limit blast radius when an account is compromised. Use this when designing roles or reviewing who has access to what.

Intent: Decision

Quick answer

  • Grant only what is needed; no extra read, write, or admin. A backup job needs read access to data, not write; a web app needs DB access, not shell access to the server.
  • Apply to humans and machines. Use separate roles for dev and prod; avoid shared admin accounts; give services their own identities with scoped permissions.
  • Review periodically; remove access when roles change or when someone leaves. Start with deny-by-default and add only the permissions that are required.

Prerequisites

Steps

  1. Define minimum required

    For each user or service, list the exact actions and resources needed (e.g. read bucket X, write to queue Y). Do not grant broader roles for convenience; create narrow roles or policies.

  2. Separate by environment and role

    Dev and prod should have different accounts or roles; do not use prod credentials in dev. Prefer one role per purpose (deploy, read-only, admin) rather than one catch-all.

  3. Deny by default

    Start with no access; add only what is needed. Avoid wildcards in policies; prefer explicit resources and actions. Audit existing roles and remove unused permissions.

  4. Review and remove

    Schedule access reviews; remove permissions when projects end or people leave. Automate where possible (e.g. deprovision on offboard) so nothing is left behind.

Summary

Least privilege means granting only the minimum permissions required. Apply it to users and services; use separate roles per environment and purpose; review and remove access regularly.

Prerequisites

Steps

Step 1: Define minimum required

List the exact actions and resources each user or service needs. Create narrow roles instead of broad ones.

Step 2: Separate by environment and role

Use different accounts or roles for dev and prod. One role per purpose (deploy, read, admin) rather than one admin for everything.

Step 3: Deny by default

Start with no access; add only what is needed. Avoid wildcards; prefer explicit resources and actions.

Step 4: Review and remove

Review access periodically; remove permissions when no longer needed or when people leave. Automate deprovisioning where possible.

Verification

Each role has only the permissions needed for its purpose; no shared super-user accounts; access is reviewed and trimmed.

Troubleshooting

Too many permissions — Create new narrow roles and migrate; then remove broad roles. Service needs more — Add the specific permission, not a broader role.

Next steps

Continue to