Come creare immagini Dockerfile arbitrarie senza Host compromettente

Question

Come creare immagini Dockerfile arbitrarie senza Host compromettente

#1 da (1 voti)
#2 da (0 voti)

5

Sto costruendo un server che costruirà immagini direttamente da Dockerfile:

docker build -t arbitrarydocker .

Questo file docker verrà creato sullo stesso server degli altri client Dockerfiles, che potrebbero avere segreti. Come posso bloccare il processo che fa docker build -t arbitrarydocker . in modo che non faccia cose come:

ADD /contents/of/host/secrets ./space/in/hacker/docker/container

Il modo migliore che posso pensare è di eseguire il fork del processo ed eseguirlo con un utente composto che ha accesso limitato alla directory a una sola cartella in cui i propri segreti sono mantenuti con funzionalità limitate. Inoltre, ti chiediamo se c'è un modo per cancellare completamente la memoria dopo che il file docker è stato creato in modo che i dati non siano trapelati alla prossima build del client.

Se l'unico modo per farlo in modo sicuro è avere un server di sviluppo dedicato per client, allora posso farlo, ma vorrei evitarlo.

Tutte le build sono fatte su Centos.

linux docker selinux centos

posta Dr.Knowitall 08.01.2018 - 22:54

fonte

2 risposte

Leggi altre domande sui tag linux docker selinux centos

È sicuro utilizzare CORS per implementare SSO? Quali sono i problemi di privacy con l'invio basato su cloud in antivirus?

score 1 · Answer 1

Indicherò l'ovvio qui e dirò semplicemente, "non includere / contents / of / host / secrets nel tuo builder VM." Presumibilmente, però, hai qualcosa sta succedendo che rende la risposta ovvia meno ovviamente corretta.

Quindi cerchiamo di tornare all'altro punto ovvio, e fai notare che "build arbitrarie di Docker" è letteralmente "esecuzione arbitraria di codice", dato che il processo di compilazione di Docker è imperativo (non dichiarativo) e che il tuo file di dock fa cose come il download e l'esecuzione di codice arbitrario da Internet è Totally A Thing ™ nel mondo di costruzione Docker.

In altre parole, l'intero processo di generazione di Docker è potenzialmente dannoso, quindi dovresti pensarci in termini di codice sandboxing fornito da un utente malintenzionato. È necessario un strong limite di sicurezza tra l'ambiente di runtime del builder (attaccante) e praticamente tutto il resto. Hai sentito che i container docker non sono un limite di sicurezza, ma i container mobili controllati dagli attacchi non fanno nemmeno fingere di essere un limite di sicurezza. Il builder deve essere eseguito nella propria VM e tutto l'accesso tra esso e i propri sistemi deve essere mediato da canali di comunicazione ben definiti; nessun accesso back-door.

Con questo in mente, ripensaci a /contents/of/host/secrets . La build della finestra mobile viene eseguita sul builder VM. La VM è isolata perché non ti fidi e non ha accesso ai segreti che non hai condiviso intenzionalmente con l'aggressore. Ecco la tua soluzione sensata.

Per la pulizia: basta eliminare la VM. Riavvia nuovamente dalla tua immagine HD "pristine".

Dato che la ruota che stai inventando è stata inventata molte volte in passato, ti consiglio di esaminare le soluzioni esistenti per avere idee su come hanno risolto i problemi che hai incontrato.

score 0 · Answer 2

Potresti costruire le immagini da un contenitore non privilegiato, che aggiungerà anche una certa protezione contro altre minacce all'host (ad esempio l'esecuzione arbitraria di un comando). Kaniko è un esempio di uno strumento per fare esattamente questo.