No. The Docker socket is the interface to the Docker daemon, and anything that can talk to it can start containers, including privileged ones. OWASP says not to expose it to other containers, and notes that mounting it read-only does not make the API read-only. Treat access as root on the host.
What the socket is
OWASP's Docker Security Cheat Sheet explains that /var/run/docker.sock is the UNIX socket the Docker daemon listens on. Mounting it into a container with a volume flag gives that container the ability to send any request the daemon accepts. The cheat sheet lists "do not expose the Docker daemon socket, even to the containers" as its first rule.
It also warns that a read-only mount gives a false sense of safety: a process that can connect to the socket can still send requests that modify containers or the host. The mount flag restricts file permissions on the socket file, not what the API allows.
Why it matters
With the socket, an attacker who compromises the container can ask the daemon to start a new container that mounts the host's filesystem, runs privileged, or joins the host network. From there they control the host and often every other container on it.
This setup is common because it is convenient. Typical reasons include:
- A CI agent that builds images.
- A dashboard that shows running containers.
- A reverse proxy that discovers containers automatically.
- A deployment tool that restarts services.
Each of these is a tool you trust with root, so a flaw in any of them, or in a dependency inside them, becomes a path to the host. That is why it matters what is installed in those images; see forgotten sidecars and tools in scans.
Safer alternatives
| Need | Option |
|---|---|
| Build images in CI | Use a builder that does not need the host daemon, or run builds in disposable isolated runners |
| Show container status | Use an agent with narrow, read only access through a proxy that filters API calls |
| Service discovery | Use labels with a filtering socket proxy, or configuration pushed from your deploy tool |
| Restart services | Use your orchestrator's API with scoped credentials |
| Run Docker more safely | The cheat sheet suggests rootless mode as a hardening step |
Where you cannot avoid it, put a filtering proxy in front that permits only the specific calls required, run the consumer on an isolated host, and never expose that container to the internet.
Detecting it
Search your compose files, Kubernetes manifests, Helm charts and CI configuration for docker.sock. In Kubernetes, look for hostPath volumes pointing at runtime sockets. Add an admission rule that rejects them outside a short list of approved system workloads.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the image scan and see which findings would matter most in an image that runs with host level access.
Quick check
Does mounting docker.sock read-only make it safe?
No. OWASP notes that the read-only flag does not make the Docker API read-only, so a process that can connect can still modify containers or the host.
Why do build tools ask for the socket?
They use the host's daemon to build and run images. Use rootless or isolated builders instead, and run them on disposable runners.
How do I find sockets mounted in Kubernetes?
Search manifests for hostPath volumes that point to a runtime socket path, and block them by admission policy except for approved system components.
Where Safeguard fits
Safeguard's container image scanning and SBOM generation show what is inside images that run with powerful access, and policies and gates can stop images with known critical issues from shipping. Run a free scan.
Sources
Last reviewed: 19 October 2026.
