Hands-on Lab·Certified Kubernetes Administrator
RBAC Roles and Bindings
Four object kinds, one verb-and-resource model, and a command that answers permission questions without trial and error. Build a read-only ServiceAccount, prove it with auth can-i, then get a real 403 from inside a Pod using its own token.
Cluster Architecture and Configuration Guide 15 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 40 min
- Reviewed21 August 2026
Written against the versions above. Rule contents are choices. The deny-by-default model and the additive-only evaluation are not.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A working cluster and
kubectlwith admin rights, since creating Roles requires them. - The kubectl session guide, particularly
api-resources: RBAC rules are written in terms of API groups and resource names, and that is where you look them up. - The control plane guide, for why
--authorization-mode=Node,RBACis what makes any of this apply.
-
The four kinds, and the one thing to get right
-
auth can-i, the command that ends the guessing
-
Read the rules back, two ways
-
Generate the same objects imperatively
-
Prove it from inside a Pod, with a real 403
-
ClusterRoles, cluster-scoped resources, and cluster-admin
-
Clean up, and one deletion trap