Roles reference
Start with the Access management overview for the tenancy model and the two binding resources. Identity concepts come from the Identity overview.
Hub ships with four built-in roles: one organization role (org-admin) and
three realm roles (realm-admin, realm-editor, realm-viewer). This page
enumerates the permissions each grants. Custom roles are not supported.
The three tables below are grouped by the tier the resource lives on. Columns are the same in each: one organization role and the three realm roles.
Cells use four values:
| Cell | Meaning |
|---|---|
| RW | Read and write — get, list, create, update, delete |
| R | Read only — get, list |
| Filtered | Allowed, but only over the rows the caller can see. SelfSubjectAccessReview returns the exact predicate. |
| — | No access from this role. Access may still flow from another role or from the control plane's own RBAC. |
Realm roles apply only inside the realm their RealmRoleBinding is
namespaced to. A subject with realm-admin in prod-east has no
permissions in prod-west.
Organization-scoped resources
Cluster-scoped resources that model the organization shell.
| Resource | org-admin | realm-admin | realm-editor | realm-viewer |
|---|---|---|---|---|
realms | RW | Filtered+write owned | Filtered | Filtered |
namespaces (realm facade) | R | Filtered | Filtered | Filtered |
identityproviders | RW | — | — | — |
users | R | — | — | — |
groups | R | — | — | — |
organizationrolebindings | RW | — | — | — |
spaces | RW | R 1 | R 1 | R 1 |
spaces/registrationtoken | create | — | — | — |
lenses | Filtered | Filtered | Filtered | Filtered |
Lenses are global and carry no realm scoping. Every principal, org-admin
included, gets the same shared-or-owner filter: you see lenses you own plus
lenses shared with the organization.
Realm-scoped resources
Namespaced by realm, or filtered by the realms and control planes the caller can see.
| Resource | org-admin | realm-admin | realm-editor | realm-viewer |
|---|---|---|---|---|
realmrolebindings | RW | RW | — | — |
controlplanes | — | RW | RW | R |
controlplanes/registrationtoken | — | create | create | — |
resources | — | Filtered | Filtered | Filtered |
resources/events | — | Filtered | Filtered | Filtered |
resourcestats | — | Filtered | Filtered | Filtered |
resourcerelationships | — | Filtered | Filtered | Filtered |
resourcerelationshiptrees | — | Filtered | Filtered | Filtered |
typedefinitions | — | Filtered | Filtered | Filtered |
typedefinitions/distribution | — | Filtered | Filtered | Filtered |
crossplanepackages | RW 2 | Filtered | Filtered | Filtered |
crossplanepackages/distribution | R 2 | Filtered | Filtered | Filtered |
queries (metrics) | — | Filtered | Filtered | Filtered |
For a realm-admin, Filtered on the resource-aggregation rows means "every
row in my realm". For realm-editor and realm-viewer it additionally
narrows to what the control plane grants, per the next table.
resourcestats and metrics queries are POST-as-read
endpoints: the query arrives in the request body, so authorization is on
the create verb even though the operation only reads.
Resource reads inside a control plane
The rows above say which realms and control planes you can reach.
This table says how much of a reached control plane's contents you see.
realm-editor and realm-viewer project into an aggregation ClusterRole;
whatever verbs that ClusterRole grants is what the role can perform on
resources synced from that control plane.
org-admin | realm-admin | realm-editor | realm-viewer | |
|---|---|---|---|---|
| Reads scoped to | — | Everything synced 3 | crossplane-edit and controlplane-edit | crossplane-view and controlplane-view |
org-admin gets nothing here — it's an organization-tier role and doesn't
cascade into any realm. Bind a realm role to reach control plane contents.
One row, because the mapping doesn't vary by control-plane type: Hub passes both names and takes whichever the control plane has. What a realm role gets inside a control plane covers that, along with how the aggregation labels widen it and why per-control-plane RBAC only ever adds.
Grants every principal holds
Independent of any role binding, every authenticated principal may:
createselfsubjectreviews—kubectl auth whoami.createselfsubjectaccessreviews(what can I do?).- Read the discovery, docs and OpenAPI endpoints.
Related resources
- Access management overview
- Filtering and self-review — how
realm-editor/realm-viewervisibility inside a control plane is computed. - Workload identities