Why mounting the Docker socket into a container is root on the host

Mounting the Docker socket into a container lets that container send any command to the Docker daemon, including starting a privileged container that mounts the host filesystem. That is effectively root on the host. Mounting the socket read-only does not limit which API calls a process can make.

What the cheat sheet says

The OWASP Docker Security Cheat Sheet lists this as its first rule: do not expose the Docker daemon socket, even to containers. It states that giving someone access to it is equivalent to giving unrestricted root access to your host. It also says mounting the socket read-only does not limit which API calls a process can make, and that you should not enable the TCP daemon socket.

The read-only point surprises people. The mount flag controls whether the file can be changed on disk. It does not control what you can say through it. Talking to a socket is a write in effect, whatever the file permissions say.

What an attacker can do with it

Anyone who can reach the daemon API can ask it to create a container. They can choose a privileged container, mount the host's root directory into it, and read or change anything: other containers' data, secrets, keys, and system files. From there, they can persist, move to other systems, or tamper with images.

So a bug in any container with the socket mounted is not a container compromise. It is a host compromise.

Why teams do it anyway

• CI jobs that build images. The job container needs to run builds.
• Monitoring and management tools that list containers.
• Reverse proxies that discover services by watching container events.
• Convenience in a local development setup that later reaches production.

Safer alternatives

For builds: use a builder that does not need the host daemon. Daemonless or rootless build tools run the build as an unprivileged process. A dedicated build service isolated from other workloads is another option. Keep build agents on separate machines from production.

For discovery and monitoring: use a read-only API proxy that allows only the specific calls needed, or have the tool read static configuration instead.

For orchestrated environments: let the orchestrator handle placement, and do not give workloads access to the node's runtime socket. Treat any pod with a host path to a runtime socket as privileged.

For development: use a separate, disposable environment, and do not copy the compose file to production.

The cheat sheet also suggests running the daemon in rootless mode and using user namespace remapping, which limit what a compromised daemon grants.

How to find exposure

1. Search compose files, manifests and CI configs for the socket path.
2. In Kubernetes, look for host path volumes that point at runtime sockets.
3. Check for the daemon listening on a network port.
4. Review which service accounts or users can create privileged containers.

Pair this with the cheaper hardening steps: run as non-root, drop capabilities, and avoid the privileged flag, which the cheat sheet says adds all Linux kernel capabilities to the container.

Safeguard's policies, gates and guardrails can check configuration against your rules during review, and a free scan can show what is inside your images.

Quick check

Sources

• OWASP Docker Security Cheat Sheet

Last reviewed: 19 October 2026.