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.
Why read-only root filesystems still fail in containerised apps
A read-only root filesystem is a strong hardening step, but it only works when the application has been designed for it. Teams often treat it like a blanket hardening switch and then discover the container still needs somewhere to write caches, PID files, sockets, temporary uploads, or log output. The control is effective when write paths are deliberately separated from the immutable image.
That distinction matters because the root filesystem is only one part of the runtime storage model. If an application assumes it can write to its own install tree, the container may crash, lose state, or silently fall back to bad behaviour. A disciplined image and runtime design makes write locations explicit instead of accidental.
One useful way to think about the control is that it reduces the attack surface of the image layer, not the need for writable state altogether. A container can still be secure while using purpose-built writable mounts, provided those mounts are narrow, temporary, and owned by the right process.
What usually needs to stay writable
The most common mistake is underestimating how many applications write during normal operation. Scratch directories, framework caches, session material, spool files, and telemetry buffers often appear only at runtime, so they are easy to miss during development. If those paths are not identified before deployment, the first production failure often looks like a mysterious application defect rather than a storage design problem.
The practical pattern is to keep the root filesystem read-only and mount only the writable paths that the process genuinely needs. For transient data, an Embedded Linux and Yocto Hardening Guide shows the same basic design principle in a different environment: make immutability the default, then carve out controlled writable locations for what must change.
That is why emptyDir is often the right answer in Kubernetes for temporary state. It gives the pod a disposable write target without reintroducing broad write access to the image itself. The important judgement is to separate transient runtime state from anything that must survive restarts, because the latter needs a different storage and recovery decision.
How to design the pod so immutability actually holds
A read-only root filesystem works best when the pod spec and the application contract are aligned. The image should be built so it can start, run, and stop without writing into its own filesystem tree, while the manifest supplies explicit writable mounts for the few directories that need them. This is a design constraint, not a post-deployment toggle.
In practice, teams should verify which paths the process writes to before they lock the root filesystem down. If the application still needs logs, use a writable volume or an external logging path rather than forcing writes back into the image layer. If it needs temp files, point the relevant directory to emptyDir and keep the scope narrow. If it needs persistent state, treat that as a separate storage requirement instead of pretending the container root can absorb it.
For container platforms generally, NIST SP 800-190 Container Security is the clearest baseline for thinking about image, runtime, and orchestrator hardening together, while NIST Cybersecurity Framework 2.0 helps teams connect the same control to broader protect and recover outcomes.
Risk and Threat Considerations
A read-only root filesystem reduces one class of compromise, but it does not eliminate runtime abuse if the writable surfaces are too broad or too privileged. The main risk is false confidence: teams believe the container is immutable, then leave writable mounts for logs, temp data, or config paths that an attacker can abuse after initial access.
Failure mechanism: If the application writes to a mounted path that is more permissive than intended, an attacker who gains process-level access can tamper with runtime state, alter logs, drop files for persistence, or influence later execution through writable configuration or scripts.
Impact: The container may remain alive while its integrity degrades, which makes detection harder than a clean crash. In the worst case, a narrow hardening control is bypassed by the very writable exception that was added to make the application function.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-190, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-190 | N/A — Container Security | Container hardening and runtime storage design directly shape read-only root filesystem use. |
| Recommendation — Apply container security guidance to separate immutable image layers from explicit writable mounts. | ||
| NIST CSF 2.0 | PR.PS-01 — Baseline Configuration of Technology Assets | Read-only root filesystems are a hardening baseline for container runtime configuration. |
| Recommendation — Lock container baselines to enforce immutable root filesystems and approved writable paths. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The control is a secure configuration measure that prevents accidental write exposure in workloads. |
| Recommendation — Harden workloads by enforcing read-only roots and reviewing required write exceptions. | ||
Practitioner Guidance
What to verify: Confirm every write path the container needs before enabling readOnlyRootFilesystem, including temp directories, PID files, cache locations, and any log destination. If you cannot name the path, you probably have not mapped the runtime contract well enough.
Decision rule: If the data is transient, use emptyDir or another disposable mount. If it must persist across restarts, do not force it into the image layer, design a separate storage path and make that requirement explicit.
Common mistake: Treating log writing as a special case after the fact. Logging is often the first thing that breaks when immutability is enabled, so decide early whether logs will be sent out of process, written to a volume, or handled by the platform.
Practitioner takeaway: A read-only root filesystem is only a real hardening control when the pod has been deliberately designed around it, with every required write path mapped to a narrow, intentional, and disposable location.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org