Rischi posti dal daemon docker eseguito come root

Il daemon docker viene eseguito come root, in quanto si interfaccia con il sistema operativo host in modo molto fondamentale, tuttavia non è diverso dalla maggior parte / qualsiasi daemon di sistema che utilizza le funzionalità di Linux che richiedono tale privilegio.

Questo non significa che l'uso di docker non sia sicuro, basta che tu stia attento a come lo usi. Fortunatamente, a questo proposito sono già disponibili alcuni consigli di configurazione della sicurezza abbastanza affidabili da Docker stessi e sotto forma di sicurezza guida alla "best practice" di configurazione dal Center for Internet Security

Un paio di considerazioni pratiche di cui devi essere a conoscenza quando esegui la finestra mobile.

Innanzitutto, se qualcuno è membro del gruppo "docker" sull'host, è effettivamente root sul sistema poiché in questo caso è possibile utilizzare la finestra mobile per eseguire l'escalation dei privilegi. Quindi è necessario trattare con cura l'appartenenza a quel gruppo sugli host di produzione.

Docker utilizza le funzionalità di Linux per limitare le azioni che un utente all'interno di un contenitore può intraprendere, quindi il solo fatto di essere root all'interno di un container non significa necessariamente root automatico sull'host. Detto questo, è necessario fare attenzione con cose come montaggi di volume (quindi se si monta una directory di sistema dall'host in un contenitore, ad esempio) in quanto ciò può consentire a un utente root in un contenitore di apportare modifiche ai file sull'host.

Puoi anche ridurre le capacità fornite ad un contenitore abbastanza facilmente, il che può migliorare ulteriormente la sicurezza del processo.

Ricorda inoltre che non è necessario eseguire i processi in contenitori come root, è possibile eseguire come altri utenti con un po 'di configurazione e ciò riduce il rischio di aumento del volume.

Trovo che il modo di pensare ai contenitori sia come processi sull'host. Se si confrontano le cose in esecuzione in contenitori per eseguirle direttamente sull'host, direi che l'architettura del contenitore probabilmente aggiungerà sicurezza anziché rimuoverla, poiché si ha un'interfaccia meglio definita tra il processo e l'host e altro controllo su ciò che il processo può fare sull'host.

Inoltre non vale nulla che un'architettura di mappatura utente più ricca stia arrivando abbastanza presto alla finestra mobile ( pianificata per 1.9 ) che aggiungerà alcune ulteriori opzioni per limitare le azioni in un contenitore.

No, non lo sei.

O, per dirla in un altro modo, se ti sbagli a preoccuparti, ci sono molti esperti di sicurezza che si sbagliano allo stesso modo. Solo per fare alcuni esempi importanti:

-I esperti hanno intervistato qui riguardo Docker sicurezza e in particolare sul problema della radice daemon. Compreso un ragazzo di CERT:

Yes, that's right, Docker, and many other container technologies, need root access to do their magic. And, like any other program that needs root access, with great power comes great opportunities to wreak havoc.

As Aaron Cois, a researcher at CERT at Carnegie Mellon University recently told the DevOps publication, "One of the biggest threats I see with Docker is its positioning and the implied security in the language. The reality is that these containers don’t contain anything." With root access that's indeed the case.

Inoltre, l'esecuzione di qualsiasi cosa con i privilegi di root all'interno del contenitore apparentemente è problematica "Un processo eseguito come root (UID 0) in un contenitore ha i privilegi di livello root sull'host sottostante quando interagisce con il kernel."

Questo pezzo fornisce un po 'di più sulle specifiche dei problemi relativi allo stato della radice del daemon, in particolare, e una buona panoramica dei problemi di sicurezza che sono un po' preoccupanti con Docker in generale.

- Ecco un'ottima analisi da parte di un team che parla di una serie di problemi di sicurezza riguardanti Docker, inclusi alcuni direttamente correlati all'architettura daemon-as-root e come combatterli / mitigarli. I presentatori offrono una visione mista in qualche modo positiva della sicurezza di Docker in generale, ma chiariscono che ci sono diversi possibili vettori di minacce che devono avere in mente quando creano un set up.

Ottieni il punto, penso. (Google rivela molti più pezzi che articolano questi punti, e ho letto personalmente alcuni altri qua e là nell'ultimo anno o giù di lì.) Ora, non sto criticando Docker con un po 'di immaginazione, e sembra che se Con l'attenzione su come impostare e mantenere le cose, è possibile ridurre notevolmente le minacce che l'architettura di sicurezza di Docker è solida, ma anche solida, incluso deamon-as-root. (E certamente i contenitori sono facili e pratici da usare come all-get-out.) Ma sicuramente, torto non hai dubbi riguardo a Docker not utilizzando un buon approccio moderno che include la massima riduzione dei privilegi ragionevole (come Almeno oggi Docker).

L'articolo di Daniel Walsh, leader del RHEL Docker enablement team (quindi non il tipo di ragazzo che avrebbe motivo di combattere Docker), è interessante anche per la sicurezza di Docker. Uno dei concetti chiave è che si deve " presupporre che i processi privilegiati in esecuzione all'interno del contenitore siano identico ai processi privilegiati in esecuzione all'esterno del contenitore. ".

Questo è un articolo relativamente vecchio, luglio 2014. I container Linux (sui quali si basa Docker) si sono evoluti e nel gennaio 2014 hanno introdotto i contenitori senza privilegi che garantiscono che i processi privilegiati all'interno del container siano ora in esecuzione con privilegi degli utenti finali dal sistema host punto di vista.

Tuttavia, questa funzione non è ancora supportata in Docker ed è stata posticipata più volte.

In un'altra risposta relativa alla sicurezza di Docker ho anche menzionato diversi altri progetti orientati alla sicurezza che prima facevano affidamento su Docker lasciandolo a causa di problemi di sicurezza.

Quindi, come hai detto, Docker " promette di semplificare le nostre implementazioni e fornire una serie di altri vantaggi operativi e di progettazione ", questo è certamente vero e sembra essere l'obiettivo principale di Docker, ma come ha sottolineato Daniel Walsh, la sicurezza attraverso l'isolamento non fa parte di queste promesse.

Come spesso c'è un compromesso tra sicurezza e funzionalità. Docker sembra posizionarsi sul lato della funzionalità della scala. Decidi tu se il valore aggiunto dalle funzioni di Docker ne vale la pena.