···118118119119While Service A may use the API as intended this won't stop an attacker from exploiting it or accessing your network from another vector. Anyone who can access the port of the socket proxy can read any data about any container. Not great!
120120121121-#### Mitigating Socket Proxy Access
121121+<details markdown=1>
122122+123123+<summary>Mitigating Socket Proxy Access by running in the same Stack</summary>
122124123125*Some* of the attack vectors mentioned above can be mitigated by restricting how a socket proxy is exposed. If the service that needs docker access is on the same host that needs to be accessed then the socket proxy can be created in the same stack as the service and communication can happen on the isolated stack network, rather than over the docker bridge.
124126···172174</details>
173175174176This can be extended to remote hosts if you use [docker overlay networks](../migrating-to-traefik#swarm-and-overlay) with Docker Swarm. However, this isn't possible if you don't have Swarm setup or there are other network factors that prevent overlay networks from working across hosts.
177177+178178+</details>
175179176180## Restricting Docker API to Specific Containers
177181···255259 ports:
256260 - 2375:2375
257261 socket-proxy:
258258- image: wollomatic/socket-proxy:1.10.0
259259- restart: unless-stopped
260260- user: 0:0
261261- mem_limit: 64M
262262- read_only: true
263263- cap_drop:
264264- - ALL
265265- security_opt:
266266- - no-new-privileges
267267- command:
268268- - '-loglevel=debug'
269269- - '-listenip=0.0.0.0'
270270- - '-allowfrom=proxy-container'
271271- - '-allowGET=/(v1\..{1,2}/)?(containers).*'
262262+ image: lscr.io/linuxserver/socket-proxy:latest
263263+ environment:
264264+ - ALLOW_START=0
265265+ - ALLOW_STOP=0
266266+ - ALLOW_RESTARTS=0
267267+ - CONTAINERS=1
268268+ - INFO=0
269269+ - POST=0
272270 volumes:
273271 - /var/run/docker.sock:/var/run/docker.sock:ro
272272+ ports:
273273+ - 2375:2375
274274```
275275276276##### Configure Homepage