Docker socket proxies: ¿capa extra de seguridad o un tercero más en el que confiar?
Un self-hoster que migra de Portainer a Arcane cuestiona la recomendación de interponer un proxy de socket como wollomatic: suma seguridad, pero también otra dependencia que auditar.
Un administrador que está dejando Portainer para pasarse a Arcane ha puesto el dedo en una contradicción que le va a sonar a cualquiera que gestione Docker en su propia máquina. La documentación de Arcane recomienda interponer un proxy de socket, y pone wollomatic como ejemplo, para que la herramienta acceda solo a las funciones del demonio que realmente necesita y no a todas. Su pregunta es directa: ¿eso es una capa real de seguridad o solo un tercero más en la cadena de suministro?
Qué hace un proxy de socket
El fichero /var/run/docker.sock es la llave maestra del host. Quien puede escribir ahí puede levantar contenedores, montar volúmenes del sistema o ejecutar procesos con privilegios. Un proxy se coloca en medio y filtra: deja pasar las llamadas a la API que la aplicación necesita y corta el resto. Es decir, no cambia lo que el gestor puede pedir cuando funciona bien, limita el daño si el gestor se comporta mal.
El problema es dónde queda esa frontera. Un gestor de contenedores necesita, por definición, crear, listar, inspeccionar y borrar contenedores, así que la lista de endpoints permitidos es larga. El proxy sigue leyendo el socket real y hay que ejecutarlo con permisos sobre él. La pregunta del hilo es si el filtrado que queda por encima compensa ejecutar un binario adicional, más pequeño y con menos ojos encima que el propio gestor.
Ahí entra el argumento de la cadena de suministro. Arcane acumula más de 7.400 estrellas en GitHub y más de 80 contribuidores, según los datos que da el autor del mensaje; wollomatic es un proyecto mucho más modesto. Las cifras son suyas, no de un tercero, pero la asimetría es la habitual: cada salto en la cadena añade código que nadie audita. Un proxy mal configurado o comprometido no solo no protege, sino que se convierte en el punto por el que se llega al socket.
La decisión práctica
Lo que un administrador debería mirar antes de copiar la receta es concreto: qué endpoints expone exactamente el proxy, cómo autentica las peticiones, si permite ejecución de comandos o montajes arbitrarios, y quién mantiene ese proyecto. La recomendación existe, pero no es gratis. Cambiar Portainer por Arcane, Dockhand o cualquier otra alternativa no elimina el problema de fondo: el gestor necesita poder sobre el demonio, y todo lo que se ponga alrededor solo acota el daño cuando algo ya ha salido mal. Lo que queda por ver es si la comunidad acaba consolidando un conjunto de reglas mínimas para estos proxies o si cada uno sigue improvisando el suyo.
