Why should Amazon ECS containers use read-only root filesystems?

Why a read-only root filesystem changes the container threat model

A read-only root filesystem turns the container image layer into something the workload can use, but not rewrite. That matters because many container compromises become more durable when an attacker can drop files, alter scripts, or change startup behaviour inside the container itself. In amazon ecs, the goal is to keep the runtime state narrow and intentional, not to let the container quietly remodel its own base image.

This is especially important when the container is supposed to be ephemeral. If the root layer is writable, malware can plant persistence markers, alter application logic, or leave behind a modified binary that survives the current process. A read-only root filesystem helps keep the base image immutable at runtime, which makes tampering easier to prevent and easier to notice.

It also forces a cleaner separation between the image and the application’s actual writable state. Logs, caches, uploads, temp files, and any other runtime data should go to mounted storage that was designed for that purpose. That separation reduces the risk that application behaviour, incident evidence, and attacker modifications all get mixed into the same filesystem layer.

What still needs to be writable in an ECS task

Read-only does not mean unusable. The practical question is which paths the application genuinely needs to write to, and whether those paths can be isolated to known mounts such as a temporary directory, a volume, or external storage. If the application still tries to write under the root layer, the deployment is usually revealing a packaging or configuration problem that should be fixed rather than accommodated.

Container teams should treat write access as an exception to design, not a default setting. That usually means identifying where the application writes logs, session data, caches, PID files, certificates, or temporary artifacts, then redirecting those paths to mounted storage with the right permissions. If the app cannot operate without writing to its root filesystem, the image is often carrying too much runtime state or too much legacy behaviour.

For a broader hardening view, the same principle appears in the Container Security Guide, which frames runtime isolation, hardening, and container escape reduction as part of the same control pattern.

Why this matters for compromise containment and image hygiene

A writable root filesystem increases the blast radius of a successful container compromise. An intruder who gains code execution can tamper with the application, stage tools, modify init scripts, or try to influence what runs next time the task starts. A read-only root filesystem does not stop every abuse path, but it removes one of the easiest ways to turn temporary execution into longer-lived control.

It also helps preserve the value of the image itself. If the root layer is mutable, it becomes harder to trust that the container still matches what was scanned, signed, or promoted. That is why image integrity and runtime immutability belong together, especially in deployments that rely on repeated task replacement rather than in-place repair. For image-level controls, the Container Image Security Guide is the relevant companion material because it covers the upstream protections that make read-only runtime behaviour more effective.

Write access is also a common way that containers leak secrets or other sensitive material into locations that are later collected, copied, or reused. If a workload can modify its own filesystem freely, it is easier for an attacker to stash credentials or alter configuration in ways that outlast the initial intrusion window. For that reason, the read-only setting works best when paired with disciplined secret delivery and a clear plan for where runtime state is allowed to live. The Secrets in Docker Hub images (RWTH Aachen study) resource is useful here because it reinforces how often secrets and other sensitive material end up where they should not.

Risk and Threat Considerations

A writable root filesystem expands the opportunity for persistence, tampering, and hidden state inside the container layer. In practice, that means a short-lived compromise can become harder to evict because the attacker can alter the container’s own execution path or leave behind artifacts that survive ordinary process restarts.

Failure mechanism: The attacker or faulty application writes into the base filesystem, changes startup behaviour, or stores unplanned state in locations that were assumed to be disposable.

Impact: This can enable persistence, binary or script tampering, configuration drift, and a larger blast radius when the task is recycled or redeployed.

Practitioner Guidance

What to verify: Confirm that every required write path is explicitly mounted and that the application does not silently depend on root-layer writes for logs, temp data, cache files, or runtime state. If a service fails under read-only mode, treat that as a design signal, not an excuse to reopen the filesystem.

Common mistake: Teams often enable read-only mode and then create broad writable mounts to make the app work again. That preserves the control only in name. Narrow the writable surface area instead, and make sure the application writes to approved storage by design.

What good looks like: The container starts and runs normally, the root layer remains immutable, and all legitimate runtime writes are confined to a small set of known paths with a clear operational purpose.

Practitioner takeaway: The value of a read-only root filesystem is not just blocking writes, it is forcing the workload to prove exactly what it must write and where that state belongs.

Related resources from NHI Mgmt Group

• When does regex-based secret detection become too unreliable for production use?
• What do teams get wrong about read-only root filesystems in Kubernetes?
• How do you prevent privileged containers and host namespace sharing in Amazon ECS task definitions?
• How should security teams use root and jailbreak detection in mobile banking?