0005. RBAC on a hierarchy, not ABAC
Status: accepted, 2026-10-09
Context
Teams share nodes, projects span services, CI needs narrow tokens. ABAC (policies over attributes, e.g.
OPA or Cedar) is flexible but needs a policy language, is hard to show in a panel and hard to debug.
Decision
Role-based access on the hierarchy instance → team → project → environment → resource:
- Instance roles:
superuser (everything, users, instance settings), user.
- Team roles:
owner (members, deletion, transfers), admin (members except owners, settings, all
resources), developer (create and change resources, deploy, non-protected secrets), viewer (read).
- Project overrides: a member can be limited to some projects of a team, or given a role on one
project of a team they are not in (guest).
- Environment protection: a protected environment (production by default) needs
admin for secrets and
for changing protection; deploying to it can require admin.
- Grants share instance or team resources with other teams (a node, an AI provider pool) with a quota.
- Tokens narrow further: scope (
read < deploy < write), optional services, project, expiry.
Consequences
- Every check answers "what role does this principal have on this resource's project and team", which
services compute from the token claims plus their own resource records.
- Attributes that matter (quotas, node capacity) are explicit objects with their own UI, not policies.