Host Mounts

What host mounts are and why they matter

Host mounts extend the boundary of an otherwise isolated runtime by exposing host files or directories inside it. That makes them useful for persistence and shared tooling, but it also means the workload inherits whatever permissions, paths, and data sensitivity exist on the mounted location.

How host mounts change isolation boundaries

A mount is not just a convenience feature, it is a direct access path. If the mounted path is broad, writable, or points at sensitive host locations, the container or guest can interact with data and configuration that would otherwise remain outside its sandbox.

That is why host mounts are often treated as a trust decision rather than a simple deployment setting. The runtime is still isolated in many ways, but the mount creates a deliberate exception to that isolation for the specific files or directories that are attached.

Common uses and operational trade-offs

Teams use host mounts for logs, local development, configuration injection, data persistence, and shared utilities. These uses reduce friction and can simplify stateful workloads, but they also create a dependency on the host filesystem layout and on the accuracy of the mount path.

In practice, the same feature that makes a workload easier to operate can also make it easier to overreach. A mount that was intended for a narrow purpose may end up exposing more of the host than the workload truly needs, especially when paths are reused across environments.

Security implications of writable and privileged mounts

The security impact depends on whether the mount is read-only, writable, or used to expose highly sensitive host paths. Writable mounts can let a compromised workload alter host data, tamper with configuration, or plant artifacts that survive container restarts.

Host mounts also matter because they can bypass assumptions about filesystem containment. If a process inside the runtime can reach secrets, sockets, device files, or administrative tooling through the mount, the blast radius of a compromise increases quickly.

Risk and Threat Considerations

Host mounts create a direct bridge between an isolated workload and the host filesystem, so the main risk is accidental privilege expansion. The danger is highest when the mount is writable, overly broad, or reused across workloads with different trust levels.

Failure mechanism: An attacker who gains code execution in the runtime may abuse the mount to read sensitive files, modify host data, persist changes, or reach adjacent system components that were never meant to be exposed.

Impact: This can turn a limited container or guest compromise into host-level data exposure, configuration tampering, persistence, or lateral movement into other workloads that share the same filesystem trust boundary.

Practitioner Guidance

Why practitioners should care: Host mounts should be reviewed as part of workload access design, not only as a deployment detail. The mount path, file mode, and write access determine whether the runtime is merely using host data or effectively sharing control of it.

What to watch for: Be cautious when the mounted path contains secrets, runtime state, logs with sensitive content, service credentials, or operational files that could affect the host if changed. The narrower the mount, the easier it is to reason about blast radius.

Related resources from NHI Mgmt Group

• What breaks when a Kubernetes pod runs as root and mounts /var/log from the host filesystem?
• What is the difference between patching a host and governing the blast radius of a kernel flaw?
• What is the difference between Docker Secrets and BuildKit secret mounts?
• Who is accountable when a Docker API policy bypass exposes host secrets?