Description
When readOnlyRootFilesystem is false or defaults permit writes, a process can change the root filesystem within its file permissions. A compromise can then leave files or alter configuration in the container’s writable layer. This is separate from running as the root user, and the read-only setting does not also protect separately mounted volumes.
Potential impact
- Files can be altered or malicious files left behind during execution.
- State changes can complicate analysis after an incident or failure.
Remediation
- Apply readOnlyRootFilesystem: true and move required log, cache and temporary write paths to separate, restricted volumes. Test actual application behavior.
- Review volume write permissions, execution identity and allowPrivilegeEscalation separately. Do not assume a read-only root filesystem blocks all malicious activity.
Examples
These historical goproxy examples compare the setting only. Use a maintained, verified image for actual deployment. The Pod names differ, so creating the second Pod does not change the existing one.
Before
apiVersion: v1
kind: Pod
metadata:
name: rootfalse
spec:
containers:
- name: app
image: k8s.gcr.io/goproxy:0.1
securityContext:
readOnlyRootFilesystem: false
The root filesystem is not restricted to read-only access. File permissions still constrain what the process can write.
After
apiVersion: v1
kind: Pod
metadata:
name: roottrue
spec:
containers:
- name: app
image: k8s.gcr.io/goproxy:0.1
securityContext:
readOnlyRootFilesystem: true
The root filesystem is read-only. Separately manage volume write permissions and replacement of existing workloads.