Anche se i processi a ciclo unico girano sullo stesso kernel, Docker usa una sfilza di tecnologie di isolazione per proteggere le une dalle altre. Il focus è soprattutto sulle funzioni cardine del kernel di Linux come Cgroup e Namespace. Ogni container riceve un proprio nome host, un proprio ID del processo e una propria interfaccia di rete. Inoltre ogni container vede solo la porzione del file system ad esso assegnata. La suddivisione delle risorse di sistema come lo spazio di archiviazione, la CPU e la banda larga, avviene attraverso un meccanismo Cgroup, il quale serve a far sì che ogni container si arroghi solamente il contingente che gli spetta.
Tuttavia ai container non viene offerto lo stesso grado di isolamento realizzabile con le macchine virtuali. Nel caso in cui un cyber criminale riesca a mettere le mani su di una macchina virtuale, avrà ben poca possibilità di interagire con il kernel del sistema host che ne sta alla base. I container invece, in quanto istanze a ciclo unico di un kernel di host comune, offrono all’hacker ben più libertà.
Sebbene le tecnologie di isolamento descritte sono raggiungibili dai container, tramite importanti sottosistemi kernel, come Cgroups e componenti kernel nelle directory /sys e /proc, queste offrono agli aggressori la possibilità di aggirare le funzioni di sicurezza dell’host. Inoltre tutti i container girano su un sistema host con lo stesso namespace utente. Ciò ha come conseguenza che un container a cui viene assegnato l’accesso di root, lo mantiene poi anche durante l’interazione con il kernel dell’host. Gli amministratori dovrebbero quindi fare attenzione che i container vengano avviati esclusivamente con permessi limitati.
Anche il demone di Docker, responsabile per l’amministrazione dei container sul sistema host, dispone dei permessi di root. Un utente che ha accesso a Docker Daemon ottiene automaticamente accesso a tutte le directory sulle quali il demone può fare affidamento, così come la possibilità di comunicare attraverso una REST API, usando il protocollo HTTP. La documentazione di Docker consiglia perciò di garantire l’accesso al demone solamente agli utenti degni di fiducia.
Anche il team di sviluppo di Docker ha riconosciuto i sopracitati dubbi relativi alla sicurezza come freni per l’affermazione della tecnologia container sui sistemi produttivi. A fianco delle tecnologie di isolamento che stanno alla base del kernel di Linux, le nuove versioni del Docker Engine supportano perciò i framework AppArmor, SELinux e Seccomp, che fungono come una sorta di firewall per le risorse kernel.
- AppArmor: con AppArmor si regolamentano i permessi di accesso dei container sul file system.
- SELinux: SELinux offre un complesso sistema di regole con il quale si può implementare il controllo sugli accessi alle risorse kernel.
- Seccomp: con Seccomp (Secure Computing Mode) viene sorvegliato il funzionamento di Systemcalls.
Inoltre Docker utilizza le cosiddette Linux Capabilities, attraverso le quali si possono limitare i permessi di root, con i quali viene avviato il container del Docker Engine.
Ulteriori preoccupazioni relative alla sicurezza dipendono dalle vulnerabilità dei software in relazione alle componenti delle applicazioni, le quali vengono diffuse attraverso il registry di Docker. Essendo che teoricamente ognuno può creare delle Docker Image e metterle a disposizione nell’hub di Docker di pubblico accesso per gli appartenenti alla community, vi è il pericolo di importare un codice dannoso sul proprio sistema durante il download di un’immagine. Per questo motivo, prima del deployment di un’applicazione, gli utenti di Docker dovrebbero assicurarsi che l’intero codice che viene messo a disposizione in un’immagine per la distribuzione di container, provenga da una fonte attendibile.
A questo scopo Docker offre a partire dal 2017 un programma di certificazione [Pagina del blogpost relativo su blog.docker.com] (https://blog.docker.com/2017/03/announcing-docker-certified/) nell’ambito dell’edizione enterprise (“Enterprise Edition” o anche “EE”), attraverso il quale i provider di infrastrutture, container e plug-in, possono testare e contrassegnare come affidabili i propri software. Per ottenere un certificato, è necessario rispettare i seguenti requisiti:
- Certified Infrastructure: gli sviluppatori del software, che vorrebbero mettere le componenti infrastrutturali certificate a disposizione per l’ecosistema di Docker, devono dimostrare tramite il test corrispondente che il loro prodotto sia stato ottimizzato per poter lavorare con la piattaforma Docker.
- Certified Container: viene assegnato il certificato ufficiale di Docker ad un container solo nel caso in cui sia stato creato conformemente alle Best Practices raccomandate per Docker e se supera tutti i relativi controlli: test del software, controllo delle vulnerabilità, controllo qualità.
- Plug-in: un plug-in per Docker EE si può dotare di un certificato Docker, se è stato creato conformemente alle Best Practices raccomandate per Docker e se supera tutti i relativi controlli: gli API Compliance Test e il controllo delle vulnerabilità.
Oltre all’aumento della sicurezza per gli utenti, i certificati Docker offrono agli sviluppatori dei vari software una possibilità per far risaltare il proprio progetto tra l’enorme quantità di risorse già disponibili.