Role-based Access Control (RBAC)
Podplane uses OIDC for Kubernetes authentication. The OIDC token issued to users includes a groups claim which Kubernetes uses to identify which group(s) the user is assigned to.
Kubernetes has multiple ClusterRole resources built-in, such as cluster-admin, admin, edit, and view. However, it does not define which external OIDC groups these roles map to.
Podplane provides default group bindings for these built-in roles. The platform-rbac component maps Podplane’s default group names to the corresponding Kubernetes RBAC roles.
Default Groups
| Group | Purpose | Kubernetes role |
|---|---|---|
podplane:admins | Unrestricted cluster administration. | cluster-admin |
podplane:managers | Namespaced administration without full cluster-admin privileges. | admin |
podplane:operators | Workload operations, including shell access to running pods. | edit |
podplane:editors | Workload editing without shell access to running pods. | edit plus admission policy denying pods/exec and pods/attach |
podplane:viewers | Read-only cluster access. | view |
podplane:operators and podplane:editors both map to Kubernetes edit. The distinction is enforced by platform-rbac admission policy: operators may use pod shell access, while editors may not unless they also belong to a higher shell-capable group.
OIDC Requirements
Your OIDC issuer must let you assign users or teams to the group names above and emit those names in the token groups claim consumed by Kubernetes. Easy OIDC can be used for this, or you can bring an existing OIDC provider which supports custom groups claim configuration.
Implementation
The platform-rbac component installs the default ClusterRoleBinding resources and admission policies. Kubernetes remains the authorization source for API access; Podplane only standardises the group names and default bindings.