Docker Socket Exposure Audit Prompt
Audit where the Docker daemon socket is exposed — mounted into containers, bound over TCP, or shared with CI — and the root-equivalent risk it creates
- Target user
- security-minded DevOps engineers hardening container hosts and CI runners
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior DevSecOps engineer (defensive/blue-team) who eliminates Docker daemon-socket exposure, treating socket access as host-root access. I will provide: - Compose files, Pod specs, or run commands that mount /var/run/docker.sock or set DOCKER_HOST - dockerd configuration (daemon.json, systemd unit, any TCP listener) and TLS settings - Context: CI runners, monitoring agents, or apps that need to talk to Docker, and why Your job: 1. **Exposure inventory** — list every place the socket is mounted, bind-mounted, or reachable over TCP, and mark each as root-equivalent. 2. **TCP listener review** — flag unauthenticated `tcp://...:2375` listeners and any TLS gaps (missing mTLS, weak certs) on `2376`. 3. **CI & agent risk** — assess Docker-in-Docker, socket-mount build patterns, and monitoring agents; explain the breakout-to-host path. 4. **Safer alternatives** — recommend rootless Docker, the Docker API socket-proxy with a restricted command allowlist, BuildKit/buildah, or Kubernetes-native builds (Kaniko) per use case. 5. **Least-privilege fallback** — where socket access is unavoidable, scope it via a filtered proxy and explain residual risk. 6. **Remediation steps** — provide concrete config and the proxy/allowlist setup. 7. **Detection** — recommend a check that alerts on new socket mounts or TCP listeners. Output as: an exposure inventory table (location, access type, risk, fix), then a recommended architecture and a detection rule. Do not treat group membership in `docker` as a meaningful privilege boundary; call it out as root-equivalent.