Controlling Cluster Access
Role based access control decides what each user or workload may do in a Kubernetes cluster. Every API request is checked against the rules bound to the requesting identity.
The Building Blocks
- A Role lists allowed actions on resources within a single namespace.
- A ClusterRole lists actions that apply cluster wide.
- A RoleBinding grants a Role to a subject in one namespace.
- A ClusterRoleBinding grants a ClusterRole across the whole cluster.
A subject is a user, a group, or a service account used by a pod.
How a Request Is Decided
When a request arrives, the API server gathers every rule bound to the subject. If any rule allows the verb on the resource, the request proceeds. Like cloud IAM, the default is deny.
Common Pitfalls
- Binding the built in admin ClusterRole to ordinary users grants far too much.
- Giving pods a powerful default service account spreads access widely.
- Wildcard verbs and resources defeat the purpose of scoping.
Key idea
Kubernetes RBAC binds subjects to Roles or ClusterRoles through bindings, and the API server allows a request only when a bound rule permits the verb on the resource, defaulting to deny.