Riesgos de usar un contenedor raíz para administrar el demonio Docker

Mi intención es crear / mostrar / eliminar imágenes y contenedores automáticamente con Docker.

Según las pautas de seguridad de Docker, exponer el daemon de Docker a un puerto es un alto riesgo para la seguridad, ya que cualquiera puede conectarse y usarlo:

  

Puede configurarlo en 0.0.0.0:2375 o en una IP de host específica para dar acceso   A todos, pero eso no es recomendable porque entonces es trivial.   para que alguien obtenga acceso de root al host donde está el demonio   corriendo.    ^{fuente 1}

Otra posibilidad es ejecutar un contenedor en modo 'privilegiado' que estará a cargo de crear contenedores DENTRO de un contenedor docker (docker-russian-doll). Pero tiene algunos problemas como se describe en aquí .

Estaba pensando en una tercera opción:

1. Cree una imagen mínima que monte el zócalo internamente, por ejemplo con docker-compose:

   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
   

2. Escriba un pequeño cliente (con Java, por ejemplo) que se conecte al socket y lo exponga con un --yet-another-although-minimal REST API

3. Deje que ese contenedor se ejecute como usuario root

4. Vincule cualquier contenedor que desee crear imágenes / contenedores mediante enlaces acoplables, por ejemplo, con acoplar-compilar.

Suposiciones:

• El enfoque es para proyectos favoritos, no quiero configurar una red privada o similar
• La idea es crear imágenes / contenedores con un enfoque minimalista
• No se almacenarán datos críticos ni se ejecutarán aplicaciones críticas en estos hosts

Basándome en la premisa de que los enlaces entre contenedores son comunicaciones "seguras".

Preguntas:

1. ¿Es este contenedor raíz con una capa de API REST mínima más seguro que exponer el socket como IP: PORT?

2. ¿Este enfoque reducirá las posibilidades de que un atacante intente obtener control sobre el socket?