Kubernetes RBAC mistakes that quietly hand out cluster admin

The most common RBAC mistakes are wildcard rules, ClusterRoleBindings where a RoleBinding would do, use of cluster-admin for routine work, and granting rights that look harmless but expand access, such as listing Secrets or creating pods. Kubernetes documents each as a risk, and each can be found in a review.

Wildcards grant more than you can see

The Kubernetes RBAC good practices page warns that wildcard permissions cover not only all object types that exist now but also every type created in the future. A rule that was fine in 2024 can grant access to a custom resource installed in 2026. Name resources and verbs explicitly.

ClusterRoleBinding where RoleBinding would do

A RoleBinding gives rights inside one namespace. A ClusterRoleBinding gives them everywhere. The docs recommend RoleBindings where possible, so users get rights only within the namespace they work in. Search for ClusterRoleBindings that bind a team group to a broad role and ask whether a namespace binding would serve.

cluster-admin and system:masters

The docs say not to use cluster-admin unless specifically needed, and suggest that an account with impersonation rights can reduce accidental changes. Members of the system:masters group are worse: they bypass all RBAC checks and webhook authorization, and removing a binding cannot revoke that access.

Also review bindings to system:unauthenticated and remove them where you can.

Rights that quietly become more

Three permissions deserve attention because they imply others.

Listing or watching Secrets. The docs note that a list response includes the data, so a plain list exposes every Secret it covers. Get, list and watch all reveal contents.

Creating pods or workload resources. Per the docs, this implicitly grants access to Secrets, ConfigMaps and mountable volumes in that namespace, plus the API access of any ServiceAccount there. A privileged pod can lead to node access.

Creating PersistentVolumes. Arbitrary volumes can allow hostPath, which exposes the node's filesystem to pods.

Pod creation is the one teams miss, because it feels like a deployment right and not a secrets right.

A review routine

Run it quarterly and after any reorganization:

1. List all ClusterRoleBindings and ask who needs each one.
2. Search roles for wildcard verbs, resources or API groups.
3. List subjects that can create pods, read Secrets, or create volumes.
4. Check service accounts bound to powerful roles and where their pods run.
5. Remove bindings for departed users. The docs warn that a reused username can inherit old rights.

Pair this with Pod Security admission so that pod creation cannot lead to a privileged pod. See Pod Security Standards: Baseline vs Restricted.

Quick check

Sources

• RBAC good practices, Kubernetes documentation

Last reviewed: 19 October 2026.