CKS Practice Question 10: Container Immutability Readonly Rootfs
Certified Kubernetes Security Specialist (CKS) · Test 1 · question 10 of 10
Runtime alerts show that an attacker who exploited a web container wrote a crypto-miner binary into /usr/local/bin and executed it in place. You are asked to make the container filesystem immutable so that this specific technique fails. The application legitimately writes cache files to /var/cache/app and scratch files to /tmp, and its image must not be rebuilt.
Which change satisfies both the hardening requirement and the application's write needs?
Show answer and explanation
Answer:
readOnlyRootFilesystem: true mounts the container's root filesystem read-only, so a write to /usr/local/bin fails outright; the miner can never be dropped onto disk in the image layers. The standard companion move is to grant back only the paths the application genuinely needs by mounting writable volumes over them; an emptyDir at /var/cache/app and /tmp gives ephemeral, Pod-scoped scratch space without rebuilding the image. This combination is exactly what the Kubernetes security checklist means by enforcing a minimal read-only root filesystem.
Option A is good hygiene and blocks a different attack (gaining extra privileges), but a non-privileged container can still write anywhere its user has permission, so the miner is still dropped and run.
Option C is invalid on two counts: readOnlyRootFilesystem is a container-level field only (it does not exist in the Pod-level securityContext), and mounting a volume at / is not a supported way to run a container image.
Option D reduces impact but does not stop the technique. The attacker runs as the application's own user and can write to any directory that user can write to, commonly /tmp or the app directory, and execute from there.
Reference: Security Checklist