Hands-on Lab·Kubernetes and Cloud Native Associate
RBAC: Roles, ServiceAccounts and Bindings
A ServiceAccount starts able to do almost nothing. Four commands give it exactly one permission - and the same check in a different namespace still answers no, because a Role stops at its namespace edge.
Security and the 4C Model Guide 25 of 46 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
The restricted profile tightens over time, which is what enforce-version=latest opts into. Pinning a version is the alternative and has its own cost.
- AuthorizationNode,RBAC
- Admission pluginsNodeRestriction (explicit) plus the defaults
| 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-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a workload needs API access and you want to grant the least that still works. This matters because a ServiceAccount starts able to do almost nothing, and every permission after that is two objects - one describing what may be done, one describing who may do it.
- listing what a brand-new ServiceAccount can already do with
kubectl auth can-i --list --as= - confirming it cannot delete Pods, and noticing
auth can-iexits non-zero so it works inside a script - creating a Role and a RoleBinding, and seeing why the model splits permissions from subjects
- asking the same question in two namespaces and getting yes in one and no in the other
Before you start
- The
psa-strictnamespace from the previous guide, or any namespace you can write to. kubectl auth can-i, which needs no extra permissions to use.
-
What a new ServiceAccount can already do
-
Confirm it cannot do the thing
-
A Role and a RoleBinding
-
Yes here, no there