No. Mounting the Docker socket into a container lets that container send commands to the Docker daemon, and the daemon runs as root unless you use rootless mode. Docker's documentation says only trusted users should control the daemon, so any container with the socket should be treated as trusted with the host.
What the socket is
The Docker command line talks to the daemon over a Unix socket. Docker's security page explains that this lets you use traditional Unix permission checks to limit access to the control socket. When you mount that socket into a container, the process inside can use the same API your command line uses.
Why that is dangerous
Three statements from Docker's documentation fit together.
First, the daemon requires root privileges unless you opt in to rootless mode.
Second, only trusted users should be allowed to control the daemon, and the page warns that crafted API inputs could let an attacker create arbitrary containers.
Third, bind mounts of host paths are not restricted by default. The page's example makes a container's host directory the host's root, and warns the container can alter the host filesystem without any restriction.
Put together, a process that can call the API can start a new container with the host filesystem mounted. That is host level access. This is an inference from the documented behavior, not a quoted claim, but it is how the risk is commonly described.
Common reasons teams do it
- CI jobs that build images.
- Monitoring or log agents that list containers.
- Local development tools and dashboards.
- Deployment helpers that start sibling containers.
Each has an alternative.
Safer options
For image builds, use a builder that does not need the host daemon, or run builds in an isolated, disposable environment such as a dedicated VM or ephemeral runner. Docker also documents secure build mounts for credentials, see how to pass secrets to a Docker build.
For monitoring, use an agent with a narrow, read-only interface where one exists, and review what it can reach.
If you must expose the API over the network, Docker says it is mandatory to secure it with HTTPS and certificates, and that exposing it over plain HTTP is not permitted. SSH is another documented option.
Consider rootless mode, which the docs mention as the way to run the daemon without root.
In Kubernetes
A hostPath volume that points at a container runtime socket carries the same risk. The Baseline Pod Security Standard disallows hostPath volumes, so enforcing it blocks this pattern. Check your system namespaces separately, because they are often exempted.
Quick check
Is a read-only socket mount safe?
Not on the reasoning here. A read-only mount flag affects the socket file, not what the API lets the caller do. Verify with Docker's guidance before relying on it.
What is the quickest improvement?
Find every compose file, CI job and manifest that mounts the socket, and ask whether it can be removed.
Sources
Last reviewed: 19 October 2026.
