Skip to main content

SocketProxy: Acceso controlado al daemon de Docker

SocketProxy es la capa que uso para interponer un control estricto entre cualquier servicio y el daemon de Docker. Sirve como filtro: permite leer información del estado de los contenedores sin dar acceso directo al docker.sock, que por defecto otorga privilegios equivalentes a root.

La utilidad principal es reducir superficie de ataque y limitar qué pueden hacer aplicaciones que necesitan consultar Docker. En lugar de montar el socket de Docker en cada contenedor —algo que concede demasiados permisos— este proxy actúa como mediador y solo expone aquellas operaciones que yo habilito explícitamente.

En resumen: evita accesos completos al daemon, controla qué endpoints están permitidos y mantiene aislados los servicios que solo necesitan lecturas.

Características

  • Proporciona acceso filtrado al socket de Docker.
  • Permite limitar operaciones peligrosas (POST, start, stop…).
  • Evita montar el docker.sock en servicios que solo necesitan lecturas.
  • Funciona como puente interno a través de una red dedicada.

Requisitos previos

  • Docker ya instalado y funcionando.
  • Servicio que necesite consultar el estado de contenedores (Homepage en mi caso).
  • Red interna exclusiva para este proxy.

Implementación

El contenedor queda así, sin puertos expuestos y usando únicamente la red propia:

El docker-compose completo se mantiene en Gitea, siempre actualizado:

Docker Compose en Gitea

Integración con otros servicios

Cualquier servicio que necesite consultar contenedores (como Homepage) se une también a SocketProxy_NET y utiliza:

DOCKER_HOST=tcp://SocketProxy:2375

No hay puertos expuestos al host. Todo ocurre dentro de la red interna.

Errores comunes o decisiones importantes

Exponer el puerto 2375 es un riesgo serio

Al principio usaba 2375:2375 para hablar con el proxy. El problema es que 2375 es un puerto sin TLS ni autenticación, y cualquier equipo de la red podría conectarse al daemon si se deja abierto.

Razones para evitarlo:

  • Cualquier dispositivo de la LAN podría enviar comandos a Docker.
  • Malware doméstico suele escanear este mismo puerto.
  • Aunque el proxy limite operaciones, sigue siendo una superficie crítica.
  • La exposición del proxy anula parte del aislamiento que proporciona.

Por eso ahora el acceso ocurre solo dentro de SocketProxy_NET, sin puertos publicados.

Resumen breve

  • Proxy del socket para controlar permisos.
  • Red dedicada SocketProxy_NET.
  • Sin exponer 2375 al exterior.
  • Servicios clientes usando DOCKER_HOST=tcp://SocketProxy:2375, depende de la configuración, pero es asi o similar.

Referencias

Back to top