## TL;DR
The Docker daemon socket is root-equivalent: anyone who can talk to it can start privileged containers. Never mount it into containers, restrict who can read it on the host, and prefer TLS-protected TCP or a socket proxy when remote access is needed. One exposed socket is a full host compromise.

## The query
```
how to secure the Docker daemon socket
```

## Use this when
- You run Docker on hosts and want to audit who can reach the daemon socket
- A tool asks you to mount the Docker socket into a container and you want the safer alternative
- You need remote Docker API access and want it behind TLS instead of plain TCP
- You are writing a Docker host hardening baseline

## Not for
- Hardening container images, registries, or runtime flags; this is the daemon control plane
- Kubernetes clusters; the equivalent concern there is API server and kubelet access
- Debugging why docker commands fail with permission errors; that is group membership, not this

## Steps
1. Find every place the socket is exposed. Check socket file permissions at /var/run/docker.sock, look for `-v /var/run/docker.sock` mounts in running containers, and search compose files for the same. Expected output: a list of every container and user with socket access.
2. Remove socket mounts you do not need. Most tools that ask for the socket can use the Docker API over TLS or a filtered proxy instead. Expected output: zero containers mounting the raw socket, or a documented list of the ones that must.
3. Tighten the socket file permissions. It should be owned by root and the docker group, mode 660, and only trusted users should be in the docker group (membership is root-equivalent by design). Expected output: `ls -l /var/run/docker.sock` shows root:docker and 660, group membership is reviewed.
4. If remote API access is needed, use TLS. Enable the daemon TLS options with server and client certs, and never expose the API on plain TCP. Expected output: remote docker commands work with certs and fail without them.
5. Consider a socket proxy for tools that must have access. A filtering proxy exposes only the API endpoints the tool needs instead of the full daemon. Expected output: the tool works through the proxy and a direct socket mount is no longer present.
6. Audit on a schedule. Socket access drifts when people debug things at 2am, so re-run step 1 monthly. Expected output: the monthly check comes back clean or flags new mounts to review.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AfWezMzh_4wm9Kh5VbABOA