Teams often assume a read-only root filesystem will work without planning for temporary write needs. The common mistake is forgetting that applications still need a writable location for scratch files, logs, or runtime state. The safer pattern is to keep the root filesystem read-only and mount an emptyDir volume for transient data that can disappear with the container.
Where Read-Only Root Filesystems Fit in Kubernetes
A read-only root filesystem is a container hardening measure, not a complete application readiness check. It reduces the chance that malware, sloppy code, or misbehaving processes can alter the image layer, but it does not remove the need for writable paths. In Kubernetes, the setting only works cleanly when the workload’s writable needs are explicitly designed around it.
The practical question is not whether the root filesystem can be locked down, but whether the application knows where it can safely write. Teams that treat the setting as a drop-in control often discover the failure only after startup, when the process tries to create cache files, lock files, temp artifacts, or logs in a path that is no longer writable.
What Teams Commonly Miss About Writable Paths
The most common mistake is assuming that “read-only root” means “no writes anywhere.” That is too strict for most workloads. Even well-built applications usually need a transient write target for temporary state, scratch space, dependency caches, PID files, or runtime-generated data. If those paths are not redirected, the pod may crash, loop, or silently degrade.
The right pattern is to separate immutable application files from ephemeral data. Kubernetes gives you that flexibility by letting you keep the container root read-only while mounting a writable volume, often an emptyDir, for the specific directories that need it. The control works because the container image stays immutable, while the application still has a defined place for short-lived writes.
NIST SP 800-190 Container Security is useful here because it frames container hardening as a combination of image integrity, runtime restrictions, and orchestrator configuration. The filesystem setting is only one part of that model.
Why the Control Helps, and Why It Still Fails in Practice
A read-only root filesystem limits post-compromise tampering and makes some container escapes or persistence attempts harder. It also reduces accidental modification of image contents, which is valuable for integrity and repeatability. But the control does not protect against an application that was never designed with explicit writable boundaries, nor does it stop writes to any mounted volume that remains writable.
Teams also underestimate the difference between “the container starts” and “the application is actually functional.” Some workloads do not fail immediately. They may appear healthy until a path is first exercised, then break under load, during log rotation, or when a library tries to materialize cache state. That is why testing must include realistic runtime behavior, not just pod admission or a basic smoke test.
Massive Docker Hub Secrets Leak and Docker Hub Auth Secrets in Container Images reinforce the same operational lesson: image hygiene matters, but you still need to control what can be written, where, and for how long.
How to Design the Pod So the Setting Actually Works
The clean implementation is to identify every write dependency before enabling the read-only root filesystem. Then map each dependency to an explicit writable mount, keep the mount scope as narrow as possible, and avoid turning transient data into durable state by accident. If the application truly needs persistence, a temporary volume is the wrong fix and the design needs to change.
NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both support the broader discipline of constraining system behavior, reducing unnecessary write paths, and verifying that configuration matches the intended control outcome.
Risk and Threat Considerations
Read-only root filesystems reduce the blast radius of a compromise, but they can create a false sense of safety if teams forget that writable mounts, environment variables, sidecars, and secrets volumes still expose attack surface. The control is most effective when it blocks persistence and tampering, not when it is treated as a blanket hardening badge.
Failure mechanism: An application or attacker uses an allowed writable path, such as an emptyDir or mounted volume, to place temporary payloads, drop artifacts, or preserve malicious state after restart.
Impact: The pod may keep running while integrity and containment assumptions are weakened, and the workload can still be abused for persistence, data staging, or lateral activity through the writable surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Read-only roots depend on enforcing secure configuration states. |
| SI-7 — Software, Firmware, and Information Integrity | The control reduces tampering risk by protecting image contents and runtime integrity. | |
| SC-28 — Protection of Information at Rest | Writable mounts and ephemeral storage still need protection boundaries in containerized workloads. | |
| Recommendation — Enforce immutable container settings and verify write paths match the approved configuration. Use integrity controls to detect unauthorized changes to container filesystems and artifacts. Limit sensitive data exposure in container storage and keep transient write areas narrowly scoped. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Read-only root filesystems are a secure configuration choice for containers. |
| Recommendation — Harden container configurations and validate that each workload can run with restricted write access. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Container storage choices affect how data is protected while the pod runs. |
| Recommendation — Protect data in mounted volumes and restrict where transient data can be written. | ||
Practitioner Guidance
What to verify: Confirm every expected write path before enabling the setting, including temp directories, log targets, language runtime caches, PID files, and any library-specific scratch locations. If a path is not explicitly mounted, assume it will break the workload or be redirected somewhere unintended.
Decision rule: If the workload needs ephemeral writes only, keep the root read-only and give it a narrow emptyDir or equivalent scratch mount. If it needs durable state, redesign the storage model rather than widening write access to the image layer.
Practitioner takeaway: The control is successful only when immutability is paired with deliberate write design, otherwise the pod becomes either broken or quietly less secure than the policy suggests.
