ServiceAccounts, Roles and RoleBindings
Every Pod runs as a ServiceAccount whether you choose one or not, and by default it can do nothing. Granting it one permission takes three objects and three commands, and `kubectl auth can-i --as=` answers whether it worked without deploying anything. This does that, then calls the API from inside the Pod to show the allowed request succeeding and the forbidden one returning 403.
Configuration and Security Guide 29 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 16 min
- Reviewed23 August 2026
Written against the versions above. The token in a Pod is a projected, time-bound token - `expirationSeconds` reads 3607 here, so it is rotated roughly hourly by the kubelet. Kubernetes no longer creates a permanent Secret per ServiceAccount, which is why `kubectl get secrets` in a namespace with ServiceAccounts is usually empty.
| 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 cluster and kubectl, with permission to create Roles and RoleBindings.
- The session creates namespace
ckad-sa, a ServiceAccountreader, a Role limited to reading Pods, a RoleBinding, and two Pods - one using the token and one with it turned off.
-
A ServiceAccount, and what it cannot do
-
One Role, one RoleBinding
-
Proving it from inside a Pod
-
Turning the token off