Access
A read-only answer to “who can touch this cluster?”
It lists two groups:
- Explicitly assigned cluster-scoped members — Cluster Admin, Cluster Maintainer, Cluster Viewer.
- Workspace-wide admins — Admin and Org Admin. These users reach every cluster by role rather than by assignment, so they never appear in a cluster’s member list. They are listed separately here rather than silently omitted, because omitting them would make the tab lie.
Assignment itself happens on the Users page, not here.
The five roles
Section titled “The five roles”| Role | Scope | Typically | Can |
|---|---|---|---|
| Admin | Workspace-wide | Full superuser | Everything: billing, SSO, audit log, users, every cluster. |
| Org Admin | Workspace-wide | Team lead | Manage members and clusters across the org. Not billing or SSO. |
| Cluster Admin | Per-cluster | Cluster owner | Full control of assigned clusters — settings, rescans, disconnect and delete. |
| Cluster Maintainer | Per-cluster | SRE / on-call | Read plus operational access — rescan, settings. No disconnect or delete. |
| Cluster Viewer | Per-cluster | Auditor | View only — dashboards, logs, metrics. No write actions. |
API keys are not roles
Section titled “API keys are not roles”An API key (rk_…) authorizes exactly as the user who created it does, but carries no
role — org and user administration is out of reach from a key by design. See
Credentials.
