# What is role-based access control (RBAC)?

> Role-based access control gives permissions to roles such as Reader or Admin, and roles to people, rather than to each person. How it works for team secrets.

URL: https://crunu.com/learn/rbac
Language: en
Updated: 2026-10-30

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](https://csrc.nist.gov/glossary/term/role_based_access_control)). 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](https://crunu.com/learn/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:

| Level        | Roles                                                                                                                                                                  |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Organization | Owner, Admin, Member                                                                                                                                                   |
| Environment  | Editor (reads and writes), Reader (reads), Specific files (sees only selected files), Operator (no key, sees no values, enrolls machines and requests access for them) |

**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.

*Figure: Example: Priya Natarajan edits Kiteline’s “Developers” access profile. In the “Add environments…” window the Editor role is selected, and the quick picks “All development” and “All staging” have ticked five environments while the production column stays empty. Behind it, the access profile page shows version 2, signed by Priya, and its two members, Jonas Lindqvist and Tom Halvorsen, who both get the change. The server stores the signed access profile but can’t change it.*

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](https://crunu.com/learn/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](https://crunu.com/guides/share-env-files-with-a-team), and the docs page [roles](https://crunu.com/docs/concepts/roles) lists every permission.

## Sources

- [NIST CSRC glossary: role-based access control](https://csrc.nist.gov/glossary/term/role_based_access_control), checked October 30, 2026.