Container Docker, variabili di ambiente e database

6

Le variabili di ambiente (impostate con -e ) nei contenitori Docker sono disponibili per ogni contenitore collegato.

Considera un tipico caso d'uso, un database. L' immagine MySQL ufficiale fornisce questo comando di esempio:

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

Ho appena inserito la mia password come testo normale in una variabile di ambiente. Per essere sicuro, devi docker inspect per vederlo, e se puoi farlo, significa che hai accesso root al sistema operativo host, che è comunque il gioco ... Quindi andiamo avanti.

Ora voglio anche creare un wiki. Usiamo questa immagine MediaWiki . Dobbiamo anche collegare il database:

docker run --name some-mediawiki --link some-mysql:mysql -d synctree/mediawiki

Oops! Quando ho collegato some-mysql , le variabili di ambiente si sono propagate e ora some-mediawiki può vedere anche MYSQL_ROOT_PASSWORD ! Ciò significa che se qualcuno dovesse compromettere il wiki, potrebbe potenzialmente anche trovare la password di root, e poi entrare nel database con esso attraverso il link.

C'è stata qualche discussione da parte degli sviluppatori di Docker su questo, e la conclusione è che le variabili d'ambiente non sono mai state pensate per condividere segreti in ogni caso, ed è un errore usarle in questo modo. Eppure tutto il tempo che vedo le immagini che passano la password come una variabile di ambiente, anche molte immagini di database ufficiali fanno questo. Perché?

    
posta Superbest 12.08.2015 - 23:27
fonte

2 risposte

2

Una risposta chiara alla tua domanda può venire solo dai manutentori delle singole immagini che sono "sbagliate" -utilizzando questa funzione, tuttavia alcune possibili spiegazioni sono

  • Non sono consapevoli dei rischi. Docker è una tecnologia relativamente nuova per molte persone e le "migliori pratiche" non sono sempre chiare per tutti, anche se gli sviluppatori di docker hanno fatto grandi sforzi in questo senso con cose come la guida CIS
  • Sono consapevoli dei rischi ma hanno deciso che non è un problema serio per la loro particolare architettura. Questo può essere il caso, ad esempio dove altri aspetti del sistema significano che i contenitori collegati sono tenuti a fidarsi l'uno dell'altro, quindi il compromesso di un contenitore porta facilmente al compromesso dell'altro, indipendentemente dalla condivisione della variabile d'ambiente.
  • Sono consapevoli dei rischi, ma mancano di un'alternativa migliore. In definitiva, la gestione delle password di servizio è un problema difficile da risolvere bene e, a seconda del software in uso sui container, potrebbe non esserci un'opzione che i gestori ritengono possa funzionare così come l'utilizzo di variabili di ambiente.
risposta data 13.08.2015 - 10:09
fonte
0

Se non si è su una macchina multi-tenant, questo non dovrebbe essere un problema. D'altro canto, il compromesso di un servizio significa che entrambi vengono colpiti. Questa è la ragione principale per le configurazioni multi-macchina con vm o microservizi separati da qualche altra parte.

    
risposta data 11.12.2015 - 15:09
fonte

Leggi altre domande sui tag