Hands-on Lab·Certified Kubernetes Administrator
securityContext and Non-Root Containers
Containers run as root unless you say otherwise. Set a non-root user, drop every capability, make the root filesystem read-only, and then find out which of those settings produced the error when a write fails.
Configuration and Secrets Guide 37 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 30 min
- Reviewed21 August 2026
Written against the versions above. UID values are arbitrary choices. The enforcement behaviour is 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
kubectl. - The Pods guide.
securityContextappears at two levels of a Pod spec and knowing the shape helps. - An awareness that this is the Pod-level half of container security. Pod Security Admission enforces these settings cluster-wide and has its own guide.
-
The default is root, and that is the problem
-
Confirm who it is
-
Which setting actually blocked the write?
-
Clean up