tl; dr : le soluzioni contenitore non garantiscono mai e non garantiranno mai l'isolamento completo, ma se necessario, utilizza la virtualizzazione.
Approccio bottom up e top down
Docker (e lo stesso vale per le soluzioni di container simili) non garantisce l'isolamento completo e non può essere confuso con la virtualizzazione. L'isolamento dei container si ottiene aggiungendo alcune barriere tra loro, ma utilizzare ancora risorse condivise come il kernel. La virtualizzazione d'altra parte ha risorse condivise molto più piccole, che sono ora più facili da comprendere e ben collaudate, spesso arricchite da funzionalità hardware per limitare l'accesso. Docker stesso descrive questo nel articolo di sicurezza Docker come
One primary risk with running Docker containers is that the default set of capabilities and mounts given to a container may provide incomplete isolation, either independently, or when used in combination with kernel vulnerabilities.
Considera la virtualizzazione un approccio top-down
Per la virutalizzazione, si inizia con un isolamento praticamente completo e si forniscono alcune interfacce ben protette e ben descritte; questo significa che puoi essere piuttosto sicuro che uscire da una macchina virtuale è difficile. Il kernel non è condiviso, se hai qualche exploit del kernel che ti permette di uscire dalle restrizioni dell'utente, l'hypervisor è fino a quando ti trovi tra te e altre macchine virtuali.
Questo non implica un perfetto isolamento. Ancora e ancora, si riscontrano problemi con l'hypervisor, ma la maggior parte di questi sono attacchi molto complicati con un ambito limitato che sono difficili da eseguire (ma esistono anche molto critici, "facili da sfruttare".
I contenitori d'altra parte sono di tipo bottom-up
Con i container, si inizia dall'esecuzione di applicazioni sullo stesso kernel, ma si aggiungono barriere (namespace del kernel, cgroups, ...) per isolarli meglio. Mentre questo fornisce alcuni vantaggi come overhead inferiore, è molto più difficile "essere sicuri" di non aver dimenticato nulla, il Kernel di Linux è un software molto grande e complesso. E il kernel stesso è ancora condiviso, se c'è un exploit nel kernel, è probabile che si possa scappare all'host (e / o altri contenitori).
Utenti all'interno e all'esterno dei contenitori
Specialmente pre- Docker 1.9 che dovrebbe ottenere gli spazi dei nomi utente significa praticamente "radice del contenitore ha anche i privilegi di root dell'host "non appena viene trovata un'altra barriera mancante nella macchina Docker (o l'exploit del kernel). Ci sono stati tali problemi prima , dovresti aspettarti di più per venire e suggerimento Docker che
take care of running your processes inside the containers as non-privileged users (i.e., non-root).
Se sei interessato a maggiori dettagli, estep ha pubblicato un buon articolo su http://integratedcode.us spiegando gli spazi dei nomi degli utenti .
Limitare l'accesso root (ad esempio, forzando un utente non privilegiato durante la creazione dell'immagine o almeno utilizzando i nuovi spazi dei nomi utente) è una misura di sicurezza necessaria e basilare per fornire isolamento e potrebbe dare soddisfacente isolamento tra i contenitori. Usando utenti con restrizioni e spazi dei nomi utente, l'escape sull'host diventa molto più difficile, ma non si deve essere sicuri che ci sia solo un altro modo non ancora considerato di uscire da un contenitore (e se questo include l'utilizzo di un problema di sicurezza senza patch nel kernel ), e non dovrebbe essere usato per eseguire codice non affidabile.