Role-based access control (RBAC) determines which actions an authenticated identity may perform through the Kubernetes API. Authentication establishes who is making a request; authorization checks whether that user or Service Account may perform the requested action. A valid client certificate proves a user's identity, but does not by itself define their RBAC permissions. section 3.1 section 3.4
Choose RBAC objects by permission scope and recipient:
- A Role defines allowed verbs, such as get, list, and delete, for resources in a particular namespace. A ClusterRole defines permissions at cluster scope, including permissions for resources such as nodes. section 3.1.1
- A RoleBinding assigns permissions within a namespace; a ClusterRoleBinding assigns cluster-wide permissions. Bindings can grant permissions to users, groups, or Service Accounts. A ClusterRoleBinding cannot bind a namespaced Role. section 3.1.1 section 9.3.2
Grant and test pod-reading access
In the default namespace, run `kubectl create role pod-reader --verb=get,list,watch --resource=pods`, then `kubectl create rolebinding pod-reader-binding --role=pod-reader --user=carol`. Inspect the result with `kubectl get role pod-reader -o yaml` and `kubectl get rolebinding pod-reader-binding -o yaml`. Finally, test the authorization decision: `kubectl auth can-i get pods -n default --as carol` returns `yes`, while `kubectl auth can-i delete pods -n default --as carol` returns `no`. For a manifest you can retain and edit, generate the Role YAML with a dry run instead of creating it immediately. section 3.1.1
$ kubectl auth can-i get pods -n default --as carol yes $ kubectl auth can-i delete pods -n default --as carol no
Compare the two permission checks: the same user can get pods but cannot delete them in the default namespace. section 3.1.1
For an access problem, check the identity used for the request, the binding's subject and scope, then the referenced Role or ClusterRole's resources and verbs. Use `kubectl auth can-i` to verify the specific action rather than assuming that successful authentication permits it. Pods commonly access the API through Service Accounts, while human users commonly authenticate with client certificates. section 3.1 section 3.4
