Hands-on Lab·Certified Kubernetes Security Specialist
Container Immutability at Runtime
The image is a starting point, not a guarantee. This guide tampers with a normal container, then does the same thing to an immutable one, and is precise about what immutability does and does not stop.
Monitoring and Runtime Guide 34 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 14 min
readOnlyRootFilesystem is a container-level field and has been stable for years. Immutable Secrets and ConfigMaps have been GA since 1.21.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a running container must not be modifiable. This matters because the image is a starting point rather than a guarantee - without one field, an attacker can write to the filesystem it is running from.
- making two writes that should not be possible, and finding that they are
- adding one field, plus a volume for the single path that genuinely has to stay writable
- finding what is still writable, and why that is exactly the point
- completing the pattern with immutable configuration, and seeing what happens when the Pod goes
Before you start
- guide 19 - the same block, from the admission side.
-
A container an attacker can modify
-
The same container, made immutable
-
What is still writable, and why that is the point
-
The rest of the pattern