Kubernetes RBAC — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about Kubernetes Role-Based Access Control.
RBAC was not the original Kubernetes authorization model¶
Kubernetes originally used ABAC (Attribute-Based Access Control), which required a static policy file on the API server and a restart to change permissions. RBAC was introduced as an alternative in Kubernetes 1.6 (March 2017) and became the default in 1.8. ABAC still exists as a flag (--authorization-mode=ABAC) but is essentially deprecated — virtually no production clusters use it.
The cluster-admin ClusterRoleBinding is the most dangerous object in Kubernetes¶
The default cluster-admin ClusterRole grants unrestricted access to every resource in every namespace. Binding this to a user or service account is equivalent to giving them root on the entire cluster. Security audits routinely find cluster-admin bound to CI/CD service accounts, monitoring tools, and even developers' personal accounts — far more access than any of these need.
RBAC is additive only — there is no "deny" rule¶
Unlike IAM systems in AWS or Azure, Kubernetes RBAC has no deny rules. Permissions are purely additive: if any binding grants access, the request is allowed. This means you cannot grant broad read access and then deny access to Secrets — if any role binding allows Secret access, it is allowed. The only way to restrict is to not grant the permission in the first place, which requires careful role design.
Service accounts are namespaced, but ClusterRoleBindings make them cluster-wide¶
A ServiceAccount exists in a specific namespace, but a ClusterRoleBinding can grant it permissions across all namespaces. This is a common security mistake: creating a service account in a "tools" namespace and giving it a ClusterRoleBinding to manage pods everywhere. The principle of least privilege demands using RoleBindings (namespace-scoped) whenever possible and ClusterRoleBindings only for genuinely cluster-wide operations.
Kubernetes 1.24 stopped auto-creating ServiceAccount tokens¶
Before Kubernetes 1.24 (May 2022), creating a ServiceAccount automatically generated a Secret containing a non-expiring JWT token. These tokens never expired and were valid until explicitly deleted — a significant security risk. Starting in 1.24, tokens are generated on-demand via the TokenRequest API with configurable expiration (default: 1 hour). Existing non-expiring tokens were not removed, meaning many clusters still have old tokens lying around.
The escalation prevention rule stops you from granting permissions you do not have¶
Kubernetes RBAC includes an anti-escalation mechanism: you cannot create a Role or RoleBinding that grants permissions you do not already possess. If you have read-only access to pods, you cannot create a Role that grants delete access to pods. The only exception is users with the escalate verb on the roles or clusterroles resource — itself a highly privileged permission that should be tightly controlled.
Aggregated ClusterRoles dynamically compose permissions from multiple roles¶
ClusterRoles with aggregationRule labels automatically inherit rules from other ClusterRoles matching those labels. The built-in admin, edit, and view ClusterRoles use this mechanism — when you install a CRD with RBAC labels, its permissions automatically appear in the aggregated roles. This is how installing a CRD for, say, Prometheus, automatically lets cluster admins manage Prometheus resources without manually updating role definitions.
audit2rbac generates RBAC policies from audit logs¶
The audit2rbac tool analyzes Kubernetes audit logs and generates the minimal RBAC roles needed for observed API calls. This is invaluable for implementing least-privilege: run your application with cluster-admin temporarily, capture the audit log, then use audit2rbac to generate a tight role that grants only the permissions actually used. The tool was created by Jordan Liggitt, one of the principal Kubernetes RBAC designers.
The system:masters group bypasses all authorization — including RBAC¶
Members of the system:masters group are granted cluster-admin access through a hardcoded binding in the API server that cannot be removed via the API. This group bypasses all authorization webhooks and admission controllers. Client certificates with O=system:masters in the subject have permanent, irrevocable superuser access. Rotating these certificates requires regenerating the cluster's PKI — a major operational event.
Impersonation lets admins debug RBAC without switching accounts¶
kubectl auth can-i --as=system:serviceaccount:default:my-sa get pods checks whether a specific identity has a permission. kubectl --as=developer@company.com get pods actually executes the command as that user. Impersonation requires the impersonate verb on users/groups/serviceaccounts, and it is the standard way to test RBAC policies without logging in as different users.
RBAC for CRDs requires explicit role entries — they are not covered by wildcards on core resources¶
Granting pods/* access does not cover custom resources. CRDs exist in their own API groups (e.g., monitoring.coreos.com), and RBAC rules must explicitly reference these groups. A common oversight: granting a service account access to "everything" via apiGroups: [""] (the core group) and resources: ["*"], which covers pods and services but misses every custom resource in the cluster.