I Docker Container sono pronti a trasformare il settore IT

L’evoluzione dei Docker Container

Un container cattura e isola il codice di un’applicazione all’interno di un processo container al fine di far credere al codice di essere se stesso una macchina. Il container Linux originale, LXC, è un metodo di virtualizzazione a livello di sistema operativo Linux per fa girare più sistemi Linux isolati su di un singolo host.

Il Docker container è stato sviluppato come un modo per costruire singole applicazioni LXC container al fine di rendere i container più portabili e più semplici da usare.

Cosa sono i Docker Container?

Docker può creare, inviare e far girare i container. Il container racchiude il software applicativo dentro una scatola invisibile con tutto ciò che necessita per funzionare. Questo include il sistema operativo, il codice dell’applicazione, runtime, i tool e le librerie di sistema. I Docker container sono costruiti su immagini Docker. Essi sono snelli, portabili e permettono agli sviluppatori di costruire, trasferire e far girare in modo efficiente applicazioni distribuite. In aggiunta, consente ad una applicazione di essere impachettata e spostata facilmente, incrementando la semplicità dell’infrastruttura. Docker offre anche un tempo di boot ridotto che migliora l’utilizzazione delle risorse. Tuttavia, poichè i container continuano ad evolversi, crescono le preoccupazioni per la sicurezza.

Le sfide per la sicurezza

I container sono meno isolati uno rispetto all’altro se confrontati con le macchine virtuali. Il lavoro di un container è quello di impacchettare e di distribuire le applicazioni ma non tutti quelli disponibili sul web sono « trusted » e non tutte le librerie e i componenti inclusi nel container sono « patchati » e aggiornati.

Un recente studio mostra che il 67% delle organizzazioni pianifica di iniziare ad utilizzare i container nei prossimi due anni ma che il 60% afferma di essere preoccupata dai problemi di sicurezza.

1. Kernel exploit. Diversamente da una virtual machine, il kernel è condiviso tra tutti i container e l’host. Se un container causa un kernel to panic, esso farà cadere l’intero host.

2. Attacco denial-of-service (DoS). I container condividono le risorse del kernel, così se un container è in grado di monopolizzare l’accesso ad una certa risorsa, esso può privarne altri container sull’host. Il risultato è un denial-of-service (DoS). Gli utenti non sono in grado di accedere a parte o a tutto il sistema.

3. Container breakout. Attenzione ai potenziali attacchi dove vi è una scalata dei privilegi, dove un utente guadagna privilegi attraverso un bug nel codice dell’applicazione che girerà con privilegi extra. Sebbene improbabili, i breakout sono comunque possibili e andrebbero considerati quando si progetta un piano di Business Continuity.

4. Immagini “alterate”. Se un utente malintenzionato riesce a far girare una propria immagine, l’host e i dati sono a rischio. Bisogna essere sicuri che le immagni che stanno girando siano aggiornate.

5. Segreti compromessi. Quando un container accede ad un database oppure ad un servizio, esso richiederà credenziali segrete, come una chiave API o username e password. Un malintenzionato che guadagna l’accesso alle credenziali segrete avrà l’accesso al servizio.

I Docker container sono efficienti e forniscono flessibilità ma è fondamentale valutare i punti sopra prima della loro implementazione.

Cosa significano i container per l’IT e per lo sviluppo?

L’analista di Forrester, Dave Bartoletti, ritiene che solo il 10% delle aziende enterprise utilizzi al momento i container in produzione ma fino ad un terzo di esse li sta testando.

Questo è il motivo per cui Docker è stata in grado di generare $762 milioni di fatturato nel 2016. I container trasformeranno il mondo IT poichè utilizzano sistemi operativi condivisi. L’andare verso i container potrebbe permettere ai data center o ai cloud provider di risparmiare decine di milioni di dollari annualmente in energia ma tutto si gioca sulla volontà di volersi assumere un rischio.

Ci sono, tuttavia, alcune preoccupazioni che riguardano la garanzia che gli sviluppatori ancora avranno la libertà di innovare mentre utilizzano i container. Gli sviluppatori devono essere in grado di scegliere i tool e i framework che vogliono utilizzare. Questo è importante perchè gli sviluppatori raramente chiedono l’autorizzazione su quali tool devono utilizzare, piuttosto scelgono gli strumenti migliori per fare il loro lavoro.

L'utilizzo di un container potrebbe potenzialmente soffocare la creatività di uno sviluppatore.

Alla fine, la scelta se investire sui container la deve fare l’organizzazione. Con i pro e i contro che pesano allo stesso modo, tutto si riduce alla valutazione del rischio.