Rischi di usare un container root per gestire il demone Docker

La mia intenzione è creare / mostrare / eliminare automaticamente immagini e contenitori con Docker.

Secondo le linee guida di sicurezza di Docker che espongono il daemon di Docker a una porta è un alto rischio per la sicurezza, perché chiunque può connettersi e usarlo:

You could set it to 0.0.0.0:2375 or a specific host IP to give access to everybody, but that is not recommended because then it is trivial for someone to gain root access to the host where the daemon is running. ^{source 1}

Un'altra possibilità è quella di eseguire un container in modalità "privilegiata" che sarà responsabile della creazione di contenitori INSIDE in un container (docker-russian-doll). Ma ha alcuni problemi come descritto qui .

Stavo pensando a una terza opzione:

1. Crea un'immagine minima che monterà il socket internamente, ad esempio con docker-compose:

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

2. Scrivi un piccolo client (con Java per esempio) che si connette al socket e lo espone con un'API REST --yet-another-although-minimal

3. Consenti a quel contenitore di essere eseguito come utente root

4. Collega qualsiasi contenitore che desideri creare immagini / contenitori usando i collegamenti docker, ad esempio con docker-compose.

Presupposti:

• L'approccio è per i progetti di animali domestici, non voglio impostare una rete privata o simili
• L'idea è di creare immagini / contenitori con un approccio minimalista
• Nessun dato critico verrà memorizzato, né applicazioni critiche verranno eseguite su questi host

Ho basato sulla premessa che i collegamenti tra contenitori sono comunicazioni "sicure".

Domande:

1. Questo root-container con un livello API REST minimo più sicuro dell'esposizione del socket come IP: PORT?

2. Questo approccio ridurrà le possibilità di un utente malintenzionato che cerca di ottenere il controllo sul socket?