Review Docker bind mounts as host filesystem access

A convenient application mount can give a container the ability to change important host files.

Source facts

Docker bind mounts expose a host file or directory inside a container and have write access by default. Container processes can therefore modify or delete host content within that access. Mounting over a populated container path also obscures the image’s existing files. Docker documents read-only mounting as a way to prevent container-side modification through the mount.

Source: Docker documentation — Bind mounts.

Applicability

Review the exact host path, container destination and access mode of a Docker bind mount.

DSE recommendation

DSE recommends approving the exact source path and intended access mode rather than a broad parent directory. Check whether the mounted destination hides configuration or executable files shipped in the image. Keep writable data and read-only configuration separate where the application permits it. Record the host dependency so migration to another server does not silently mount a different directory. Treat a request to expose sensitive system paths as a security design decision, not merely a storage convenience.

Verification

On a nonproduction host, inspect the effective source, destination, and read/write mode. Verify permitted reads and a harmless denied write for a read-only mount. Compare the image’s original destination content with the mounted view and confirm the application sees the intended files. Use a marker file owned by the test to distinguish the host path from an image file. Retain the inspected mount definition and have the host owner approve any writable exposure before applying it to important paths.

Official reference

Docker documentation — Bind mounts. Reviewed October 20, 2026.