Mounting /var/run/docker.sock into a container is not an ordinary file share. In common Docker configurations, a process that can control the socket can ask the Docker daemon to create or manage containers, which may amount to administrative control over the host.
Why is the socket dangerous?
The socket is a control boundary, not merely a data endpoint. A compromised application with socket access may be able to use the daemon’s authority to affect images, mounts, processes, networks, and containers. The exact impact depends on daemon configuration and permissions, but the risk deserves an explicit threat model.
What should you review?
- Which containers mount the socket and why?
- Can the application be compromised through a public or untrusted input?
- Is a narrow proxy enforcing an allow-list, or is the full API available?
- Could the workload use a separate service, rootless Docker, or a build runner instead?
- Are socket mounts present in Compose files, deployment scripts, or examples?
Do not treat a read-only socket mount as a complete fix; read-only access to a control API can still be powerful.
Safer administration pattern
Prefer a dedicated, narrowly scoped service or build mechanism when possible. Remove unnecessary socket mounts, keep management paths private, and review image signing and provenance separately from runtime access.
Sources
- OWASP Docker Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
- Docker Engine security: https://docs.docker.com/engine/security/