What is role-based access control (RBAC)?

Role-based access control (RBAC) is a way of managing permissions in which actions are granted to named roles, such as Reader, Editor or Admin, and people or systems receive access by being assigned a role, so that nobody's permissions have to be listed one by one.

The idea

NIST describes RBAC as "a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities" (NIST glossary). Instead of "Jonas may read staging, write staging, read development…", you say "Jonas is an Editor on staging and development", and the role defines what an Editor may do.

Roles make three things easier:

• Granting. A new teammate gets the same roles as others in the same job.
• Reviewing. "Who is an Admin?" is a short list; "who can delete projects?" follows from it.
• Removing. Taking away a role takes away everything it granted.

RBAC and least privilege

Roles are only as narrow as you design them. With one role per job, least privilege is easy. With "Admin" and "everyone else", RBAC still works, but most people end up with more than they need. Two refinements help:

• Roles per resource, not only per organization. Editor on development and Reader on production is a different shape from Editor everywhere.
• Groups of grants, so a role set for a whole team can change in one place.

Common mistakes

• Role sprawl. A new role for every exception makes reviews as hard as individual permissions were.
• Admin by default. Giving people the top role "to avoid friction" removes the point of having roles.
• Assuming the role enforces itself. In most systems a role is a rule the server applies. If the server is compromised, the rule is too.

Roles in Crunu

Crunu has roles at two levels:

Access profiles group "environment → role" pairs, for example a Developers profile with Editor on every development and staging environment. Changing a profile changes access for everyone in it, and every version of a profile is signed.

The difference from most RBAC is where the role takes effect. Reader and Editor on an environment come with that environment's key, sealed to the person; Specific files comes with a sealed copy of only the chosen files; Operator comes with no key at all. A role therefore isn't only a server rule: someone without the key can't read the environment, whatever the server does. Who has which role is written in an access list signed by an owner or admin, so the server can't quietly add a reader either; see access control list.

What Crunu roles don't do: they have no expiry, so temporary access is removed by hand, and there is no SSO or directory sync to assign them. Day-to-day setup is covered in how to share .env files with your team, and the docs page roles lists every permission.

Sources

• NIST CSRC glossary: role-based access control, checked October 30, 2026.