// HACKER NEWS — CYBERSECURITY
There is no 10x RBAC
I recently built a simple feature most customers might never notice as a complex bit of engineering: Infisical users can now grant/deny access to single folders. This is the kind of thing that gets a brief mention in the all-hands and a one-line changelog entry.
RBAC, permissions, and authorization are the same class of engineering project as billing, schema migrations, and audit logs:
The best case is no complaints and that the system is correct. It can never excel. There's no 10x RBAC system people rave about on Twitter. Access controls are a box a product checks, but not a killer feature.
That doesn’t make them less important. Enterprise buyers will never sign an order form without them. And in secrets management (one of the categories Infisical operates in), getting access wrong means someone sees credentials they shouldn't, or a customer’s deployment fails at three in the morning because a service lost access to a secret.
Tailscale and Oso have both written about why authorization is harder than it looks. Building folder-based access taught me the same thing from a different direction.
Conceptually, RBAC is simple. Each identity, human or machine, has a role (e.g. admin, member, or guest) which carries permissions:
We use CASL, in which a basic permission attached to a role can look something like this:
This identity can read and create secrets in staging environments. CASL automatically denies anything not explicitly allowed. A role with the permission above could never touch secrets in production environments.
Role-based access is popular because humans intuitively get it. Roles in RBAC map to roles in teams, and granting/denying privileges in bulk saves time compared to manually setting permissions for each team member, which would turn access controls into a full-time job.
But not all access control changes perfectly match roles. There are two special cases for why we built folder-based access: