Skip to content
LearnLeast privilege

What is the principle of least privilege?

Also known asprinciple of least privilegePoLP
Example. Kiteline is a fictional company.
On this page

Least privilege is the security principle that every user, process and system should have only the access needed for its task, and nothing more.

Where the idea comes from

The NIST glossary entry for least privilege describes it as designing a system so that each entity gets the minimum resources and authorizations it needs to do its job, citing NIST SP 800-53 among other sources. The reasoning is simple: access that was never granted cannot be misused, stolen or leaked.

Applying it to secrets

For secrets, least privilege usually turns into a few habits:

  • separate environments, so a developer working on staging does not hold production credentials;
  • read-only access where writing is not needed;
  • one token per pipeline, scoped to the environment it uses;
  • machines that receive only the files their service reads;
  • access that is removed when the task ends, not when someone remembers.

The last habit is where most teams slip. Granting access is urgent; removing it is easy to forget.

How Crunu supports it

  • A key per environment. A member without access to payments-api / production has no key for it, so they cannot decrypt it even from a full copy of the database.
  • Roles on environments. Editor reads and edits, Reader reads, Specific files reads only selected files, and Operator adds machines and requests access for them without seeing any values.
  • Access profiles. Named sets of "environment and role", such as a Developers profile that gives Editor on development and staging. A change to the profile applies to everyone in it.
  • Access requests. A member asks for an environment; an owner or admin approves or rejects the request.
  • Machines and service tokens receive only the environments granted to them, with leases, usage limits and network restrictions.

Honest gaps

  • Owners and admins can reach all shared environments through the organization recovery key. Keep that group small.
  • Environment access for people has no expiry date. If you grant production for an incident, remove it afterwards. Expiry exists for invitations, share links, service tokens, machine leases and break-glass access.
  • Root on a machine sees everything granted to that machine, so grant machines the minimum.

See roles, access profiles and access control.

Sources

From the blog

  • Security

    One key per environment: why dev must not open prod

    Most tools separate dev and prod with permissions the server enforces. Why the boundary is stronger when each environment has its own encryption key.

  • CI/CD

    Giving CI only the secrets it needs

    Long-lived CI tokens work from anywhere until revoked. How to scope pipeline secrets, keep production out of CI, and bind tokens to a repo with OIDC.

  • Security

    Audit logs you can verify: how hash chains work

    An audit log is only evidence if nobody can quietly edit it. How hash chains make tampering visible, what they miss, and how to check an export yourself.