How to Limit Container Access to the Docker Socket With a Socket Proxy

The Docker socket is a file that lets programs send requests to the Docker daemon, the service that creates and manages containers. A container that mounts this file can affect other containers and the host. For example, it can ask Docker to start a container with a host directory mounted inside it. Docker therefore recommends allowing only trusted users to control the daemon through its Engine security guidance.

A socket proxy lets a client container use selected parts of the Docker API, the interface clients use to send instructions to the daemon. The proxy mounts the host socket and checks requests before passing them on. The client connects to the proxy over a Docker network, so it does not mount the socket itself. This limits which API requests the client can make, but the proxy remains trusted, and every allowed request still has the Docker daemon’s power.

Put the proxy between the client and Docker

The Tecnativa Docker Socket Proxy forwards requests to the Docker socket and uses environment variables to allow or block groups of API paths. For example, AUTH controls requests under the /auth/ API path. Denied requests return HTTP 403.

The proxy mounts the host socket, and the client and proxy share a private Docker network. The client uses the proxy address as its Docker endpoint. In a client that supports the Docker API, the endpoint commonly looks like tcp://socket-proxy:2375.

Keep the proxy off public networks. For container-to-container access, do not publish its port on the host; attach only the proxy and the intended client to a dedicated Docker network. The proxy project warns against public exposure and says the proxy does not provide TLS. Any other container attached to that network can reach the proxy too, so network membership is part of the access boundary.

Start with a narrow API policy

The proxy groups related Docker API paths under settings. The proxy’s README lists EVENTS, PING, and VERSION as enabled by default. It lists AUTH, SECRETS, and POST as disabled by default. Groups such as CONTAINERS, EXEC, and IMAGES need explicit access, as do NETWORKS, SYSTEM, and VOLUMES. Enable a group only after checking which Docker API operations the client needs.

This Compose file shows how to connect the proxy and client and mount the socket. Replace the image placeholders with a reviewed, pinned version and the client image you use. The file leaves CONTAINERS disabled. Many clients need that group, but enabling it has a caveat discussed below.

services:
  socket-proxy:
    image: ghcr.io/tecnativa/docker-socket-proxy:
    environment:
      EVENTS: "1"
      PING: "1"
      VERSION: "1"
      POST: "0"
      AUTH: "0"
      SECRETS: "0"
      # Enable only when required.
      # CONTAINERS: "1"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - docker-api
    # No published host port.

  app-that-needs-docker-api:
    image: your-image
    environment:
      DOCKER_HOST: tcp://socket-proxy:2375
    networks:
      - docker-api

networks:
  docker-api:

The :ro suffix makes the socket mount read-only as a filesystem mount. It does not define which Docker API requests the proxy accepts, so it is not a substitute for the proxy’s request filters. Also avoid adding --privileged automatically: the proxy project says that mode may be required in some SELinux or AppArmor contexts, but host security settings and image requirements determine whether it is needed.

After configuring the client, test its operations through the proxy. When a request receives HTTP 403, use that response to identify the API group the client needs. Grant access to only that group, then test again. Check compatibility as well: the proxy README lists supported Docker API versions through 1.51, while Docker describes client and daemon version compatibility as best-effort. Verify the installed versions and exercise the client against the proxy.

Treat POST=0 as a method restriction

Setting POST=0 restricts HTTP methods. The proxy README describes this setting as allowing only GET and HEAD requests. Those methods can still return sensitive information, so this setting does not guarantee confidential or harmless read-only access.

That distinction matters especially when a client needs the CONTAINERS API group. An open Tecnativa issue, filed August 15, 2026, reports that enabling CONTAINERS=1 allowed sensitive GET requests for container archives, exports, process lists, and logs, even with POST=0. The issue reports tests against tecnativa/docker-socket-proxy:latest and Docker Engine 29.4.3. As of the research checked November 10, 2026, it remained an issue report, not a maintainer-confirmed security advisory; the reviewed information does not establish whether a later release resolved it.

The reviewed proxy settings do not show how to let a client discover containers while blocking access to their files and logs, as well as process information. Do not treat CONTAINERS=1 plus POST=0 as sufficient for that requirement. Evaluate a different authorization mechanism or a narrowly scoped intermediary, and verify its endpoint-level rules before granting access.

Know what the proxy does not protect

The proxy reduces the number of containers that mount the Docker socket and filters API requests, but the proxy itself still needs access to that powerful socket. A client can use every operation the proxy policy allows. The proxy project also documents no TLS support, so keep it on a private network and let only clients trusted with the granted API access join that network.

SSH or TLS can protect a connection to a remote Docker daemon, as described in Docker’s daemon access guidance. Those transport protections do not automatically restrict which API operations a credentialed client can request. Docker warns that clients with trusted TLS credentials can issue daemon instructions that confer root access on the daemon host.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com