Archivi categoria: Container

Container vs. VM: qual è il piu sicuro?

Facebooktwittergoogle_plusredditlinkedin

I container sono davvero meno sicuri di una VM?

James Bottomley, ingegnere di IBM Research e sviluppatore del kernel Linux, ha fatto notare come non esistesse di fatto un metodo standard per misurare il livello di sicurezza di ciascuna tecnologia, riducendo tutto il dibattito a una questione di “sensazioni” da parte dell’utente:

Hypervisors ‘feel’ more secure than containers because of the interface breadth.

Gli hypervisor “sembrano” più sicuri rispetto ai container per l’ampiezza (in termini di user experience, nda) dell’interfaccia.

Basarsi sulle “sensazioni” per definire un qualcosa come sicuro o meno non è sicuramente il modo giusto per effettuare un paragone scientifico ed imparziale.

Prima di tutto, Bottomley è partito col definire un Vertical Code Attack Profile (VAP), ovvero tutto il codice che viene attraversato per erogare un servizio. Come tutti i software, il codice contiene dei bug più o meno importanti. Ovviamente, più codice si attraversa, maggiori sono i rischi di trovare falle nella sicurezza.

Nella seconda fase di questa ricerca, è stato creato un Horizotal Attack Profile (HAP) per misurare di fatto quante righe di codice vengono effettivamente utilizzate per una data applicazione.

A questo punto sono stati lanciati dei benchmark standard:

  • redis-benchmark, che simula l’esecuzione di comandi effettuata da N client nello stesso momento, inviando N query;
  • python-tornado, un web framework in grado di scalare fino a decine di migliaia di connessioni che richiedono connessioni long-lived;
  • node-express, web framework per Node.js su cui sono stati installati due web server con alcuni client esterni.

Questi test sono stati effettuati con Docker, gVisor, gVisor-kvm, Kata Containers, l’hypervisor built-in di Linux e Nabla (l’ultimo rilasciato in casa IBM).

I risultati?

  • Nabla si è comportato meglio rispetto a Kata, risultando cosi più sicuro di un hypervisor;
  • Docker con un profilo seccomp (che blocca chiamate di sistema non attese) configurato a modo, fornisce lo stesso livello di sicurezza di un hypervisor;
  • gVisor in alcuni casi si è comportato al pari di Docker ma in uno dei test è stato decisamente il peggiore. gVisor infatti cerca di migliorare le performance del container riscrivendo le syscall in Go, incrementando notevolmente il codice che necessita di essere eseguito.

Questo ovviamente è solo un punto di partenza, ma l’avreste mai detto che i container sono sicuri come una virtual machine?

Container Security: tante dashboard esposte su internet

Facebooktwittergoogle_plusredditlinkedin

L’uso dei container è esploso negli ultimi anni, noi stessi abbiamo trattato dell’argomento diverse volte.

Indubbiamente sono comodi: la possibilitá di testare rapidamente software senza preoccuparsi di installare le dipendenze sull’host, come anche la capacità di scalare e/o essere spostati da un sistema (o un OS) all’altro, rendono il deployment rapido e senza pensieri.

Tutta questa rapidità e comodità, però, sta portando molti utenti ad un utilizzo poco responsabile degli stessi; già, perché prima, lavorando direttamente sul proprio sistema, forse si tendeva ad essere più attenti a quello che si andava a fare, ai servizi che si esponevano, alle porte che si aprivano.

La natura di “scatola chiusa” dei container porta, evidentemente, gli utenti meno attenti a pensare di avere tutto sotto controllo, ma è giusto tenere sempre a mente che i container non sono altro che processi in esecuzione sul proprio sistema e come tali vanno trattati.

Proprio in questi giorni uno studio effettuato da Lacework, azienda che si occupa di sicurezza sul cloud, ha portato alla luce che più di 21000 sistemi di orchestrazione ed API di container sono pubblicamente esposte su internet.

Certo, seppur “solo” circa 300 di questi siano accessibili senza autenticazione, lasciando totale libertà agli attaccanti di schedulare e lanciare qualsiasi cosa su quei sistemi, la situazione è tutt’altro che rosea; anche perché ben sappiamo che nessun software è esente da bug, ed una vulnerabilità potrebbe sempre essere scoperta e sfruttata.

Come è immaginabile il 75% di queste dashboard sono esposte da Kubernetes, sicuramente l’orchestrator più utilizzato al momento, seguito da Docker Swarm con un 20% (ricordiamo che Swarm è integrato in Docker stesso).

Si ritaglia un piccolo spazio anche RedHat OpenShift, con un modesto 1%; seppur OpenShift sotto il cofano abbia comunque Kubernetes, l’avere questo sistema esposto porta ad esporre non solo il sistema di esecuzione dei container, ma tutto il processo di creazione, il registry, e tutte le eventuali chiavi di sicurezza caricate nel sistema.

Quindi, se volete utilizzare i container fate pure, sono obbiettivamente molto comodi, ma ricordate bene a cosa andate in contro. A volte basta un nmap per stare più tranquilli.

DockerHub: trovati i primi container contaminati

Facebooktwittergoogle_plusredditlinkedin

Docker è sulla cresta dell’onda da tanto tempo, troppo tempo perchè passasse inosservato.

E, prima o poi, doveva succedere: sono state rilevate le prime immagini di container contaminate, da software di crypto-mining, direttamente sul Docker Hub, il registry ufficiale e pubblico di Docker.

Il registry è un componente fondamentale in un’infrastruttura a container; è il componente da cui Docker (o sistemi che utilizzano Docker come base, ad esempio Kubernetes) scarica delle immagini di container che poi esegue sull’host; una volta fatta la build dell’immagine più o meno specializzata è possibile caricarla su un registry, che può essere privato o pubblico (come nel caso di Docker Hub) così che uno o più altri host possano utilizzare quell’immagine senza doverla rigenerare ex-novo.

Due società che si occupano di sicurezza, Fortinet e Kromtech, in questi giorni hanno pubblicato due articoli in cui rivelano che ben 17 immagini di container Docker avevano al loro interno dei miner di cryptovalute che, all’insaputa degli utenti, utilizzano le risorse delle macchine su cui questi container venivano lanciati per generare una BotNet sufficientemente ampia da trovare qualche cryptovaluta.

Queste immagini, considerate sicure, sono state scaricate ben 5 milioni di volte prima che venissero identificate e rimosse, e sfruttavano installazioni di Docker e Kubernetes configurate male per scaricare ed eseguire uno script di mining, oltre al servizio fornito ufficialmente. Il tutto, cosa ancora più preoccupante, in maniera del tutto automatica.

Of course, we can safely assume that these had not been deployed manually. In fact, the attack seems to be fully automated. Attackers have most probably developed a script to find misconfigured Docker and Kubernetes installations. Docker works as a client/server architecture, meaning the service can be fully managed remotely via the REST API

Ovviamente possiamo assumere con sicurezza che queste non siano state rilasciate manualmente. Di fatto, l’attacco sembra essere totalmente automatizzato. Gli attaccanti hanno probabilmente sviluppato uno script per trovare installazioni Docker e Kubernetes configurate male. Docker funziona in un’architettura client/server, quindi il servizio può essere completamente gestito da remoto tramite API REST

I due articoli mostrano anche gli aspetti tecnici su cui si basano questi attacchi, e spiegano che gli attaccanti sono riusciti a ricavare circa $90,000 in cryptovalute (544.74 Monero per l’esattezza) prima di essere scoperti e che le immagini venissero definitivamente rimosse dall’hub e dai sistemi.

As with public repositories like GitHub, Docker Hub is there for the service of the community. When dealing with open public repositories and open source code, we recommend that you follow a few best practices including: know the content author, scan images before running and use curated official images in Docker Hub and certified content in Docker Store whenever possible

Come per i repository pubblici come GitHub, Docker Hub è li a servizio della comunità. Quando si ha a che fare con repository pubblici aperti e codice open source, raccomandiamo di seguire alcune regole come: conoscere l’autore del contenuto, scansionare le immagini prima di usarle ed utilizzare immagini ufficiali presenti in Docker Hub e contenuti certificati nel Docker Store dove possibile.

Regole di puro buon senso, quindi, noi aggiungiamo che forse partire da immagini base ufficiali, costruirsi le proprie immagini specializzate ed utilizzare un registry privato (lo stesso Docker fornisce una semplice procedura per farlo) è la soluzione più sicura.

Red Hat annuncia rinnovate partnership con IBM e Microsoft. L’obiettivo? Container e cloud ibridi!

Facebooktwittergoogle_plusredditlinkedin

Sono molte, moltissime le notizie e le novità che emergono dal Red Hat Summit che si sta svolgendo a San Francisco. Abbiamo già trattato di Storage One, ed oggi ecco arrivare notizie del rinnovo di due delle più importanti collaborazioni fissate da Red Hat negli anni: quella con IBM e quella con Microsoft.

Red Hat e IBM hanno annunciato l’espansione della propria partnership con l’obiettivo di accelerare l’adozione di ambienti cloud ibridi. Il tutto riassunto dalle parole di Paul Cormier (president, Products and Technologies di Red Hat):

By extending our long-standing collaboration with IBM, we’re bringing together two leading enterprise application platforms in Red Hat OpenShift Container Platform and IBM Cloud Private and adding the power of IBM’s software and cloud solutions.

Estendendo la nostra duratura collaborazione con IBM stiamo mettendo insieme le due principali piattaforme per applicazioni enterprise del mercato Red Hat OpenShift Container Platform ed IBM  Cloud Private, aggiungendo la potenza dei software e delle soluzioni cloud IBM

Ma non è tutto. L’altra grande notizia di Red Hat riguarda l’ulteriore annuncio di una rinnovata e più stretta collaborazione con Microsoft per lo sviluppo del primo servizio Red Hat OpenShift gestito congiuntamente su un cloud pubblico, nella sostanza la certificazione di Kubernetes sulla piattaforma Azure. Di nuovo nelle parole di Paul Cormier:

By extending our partnership with Microsoft, we’re able to offer the industry’s most comprehensive Kubernetes platform on a leading public cloud, providing the ability for customers to more easily harness innovation across the hybrid cloud without sacrificing production stability.

Estendendo la nostra partnership con Microsoft saremo in grado di offrire al mercato la piattaforma Kubernetes più comprensiva possibile all’interno del principale cloud pubblico, fornendo l’abilità ai clienti di sfruttare con più facilità l’innovazione nei cloud ibridi senza dover sacrificare la stabilità.

Molto altro bolle in pentola a San Francisco, e non vediamo l’ora di raccontarlo!

Container… Container ovunque! Cisco, Linbit e CoreOS presentano tante novità relative a Kubernetes

Facebooktwittergoogle_plusredditlinkedin

Messaggio a tutti i reticenti nell’accettare il fatto che Kubernetes (e i container) siano la tecnologia del momento: questo trend non è destinato a scomparire a breve. Basta scorrere le notizie quotidiane in ambito informatico e ci si imbatte in qualche nuovo annuncio, prodotto o strategia che aziende del settore propongono ed incentrano sui container e su Kubernetes.

Partiamo da Cisco, che ha introdotto il supporto a Kubernetes all’interno dei suoi prodotti AppDynamics e Cisco CloudCenter, il fine ultimo è incrementare le capacità di scaling, la sofisticatezza e la velocità nell’effettuare il deploy di applicazioni mediante il famoso orchestrator di container, il tutto garantendo il supporto a topologie di applicazioni ibride e la semplificazione dell’accesso da parte di utenti senza esperienza in Kubernetes.

C’è poi Linbit, l’azienda produttrice della tecnologia DRBD, che con il prodotto LINSTOR si propone come riferimento per storage di tipo container-native. Affidandosi a DRBD per la replica dei dati, LINSTOR si pone come strato di gestione (provisioning) di storage in ambito container. La soluzione verrà presentata in uno showcase all’interno del Red Hat Summit.

Infine ecco arrivare da CoreOS l’Operator Framework! Un ambiente che vuole semplificare la gestione degli operator ossia metodi di packaging, deploying e managing delle applicazioni Kubernetes. Il framework fornisce una piattaforma SDK che vuole semplificare e rendere più furba la gestione delle applicazioni in ambito Kubernetes.

E c’è da scommettere che altre aziende, altri prodotti ed altre tecnologie sono lì che aspettano solo di essere annunciate, il mondo è dei container!

Titus: il manager di container opensource in salsa Netflix

Facebooktwittergoogle_plusredditlinkedin

Netflix non è nuova al rilascio in open source di software che ha sviluppato ad uso interno. E si vede dalla sua pagina di GitHub: da tool per interrogare sistemi di Big Data a software di build e delivery, passando da encoder fino alla cattura ed analisi delle metriche, per molte cose la filosofia dell’azienda di Los Gatos è sempre stato “aperto è meglio“.

Recentemente ha rilasciato in open source Titus, il software di gestione dei container che utilizzano internamente. Ma perchè svilupparne uno in casa invece di utilizzare i più conosciuti Kubernetes, Mesosphere DC/OS o Amazon ECS? Beh, diciamo che Netflix utilizza i container da più tempo rispetto al boom di questi prodotti ed il loro carico di lavoro è estremamente alto e settorializzato, al punto che non solo hanno preferito sviluppare internamente una tecnologia che si adattasse al 100% alle loro necessità, ma collaborando con altre aziende a cui si appoggiano, come ad esempio Amazon, hanno fatto si di far evolvere le tecnologie di quelle aziende al punto da generare interi nuovi prodotti che ora offrono ai loro clienti (mai sentito parlare della feature di “IP target groups for Application Load Balancer” fornita da Amazon AWS? Beh, è stata sviluppata a 4 mani con Netflix per risolvere problemi di quest’ultima).

E beh, se il solo nome Netflix non è sufficiente per farvi un idea di quanto possa essere testato questo nuovo prodotto open source, basti pensare che Titus al momento gestisce il lancio di, in media, mezzo milione di container al giorno, e circa 200.000 (si, mila) cluster. Oltre a questo, ruota centinaia di migliaia di virtual machine EC2 (di Amazon) ogni mese per assicurare che il carico necessario sia soddisfatto. Ah, ed il tutto in tre diversi continenti con politiche che gli permettono di migrare in maniera trasparente l’intero traffico da un continente all’altro in 7 minuti senza che le persone a casa neanche si accorgano di quello che sta succedendo.

Insomma, considerando la scala e l’importanza di quello che gestisce, sicuramente Titus è un progetto titanico e ben testato, e sicuramente può essere interessante provarlo. Certo, è molto settorializzato, quindi a meno che voi utilizziate pesantemente l’infrastruttura Amazon (EC2, AWS) per l’erogazione dei vostri servizi, forse potrebbe non essere la soluzione ideale.

Lasciamo a voi l’ardua scelta, nel frattempo in questo post di annuncio potete trovare interessanti spunti su come è stato pensato il progetto.

Buona lettura.

OpenContainerInitiative: finalmente uno standard per la trasmissione di immagini dei container

Facebooktwittergoogle_plusredditlinkedin

Due anni fa parlavamo della nascita della Open Container Initiative sotto il controllo della Linux Foundation. Con l’esplosione dell’uso dei container, e delle tecnologie in grado di gestirli, definire uno standard ufficiale ed aperto per la creazione, l’esecuzione e la trasmissione delle immagini dei container è diventato fondamentale.

E, finalmente, si inizia ad arrivare a qualcosa di completo: già in passato il formato delle immagini ed i runtime sono stati standardizzati dalla OCI, che l’anno scorso ha raggiunto una maturità con il rilascio della versione 1.0; in questi giorni il lancio del progetto Distribution Specification ha definito lo standard anche per il push e pull delle immagini (le operazioni utilizzate per caricare e scaricare le immagini da un registro), andando così a coprire (quasi) tutto il mondo container: come viene creato, come viene eseguito e come viene trasmesso.

Per questa operazione hanno deciso di basarsi sulla definizione del Docker Registry V2; essendo questo un registry dei più utilizzati al mondo (forse il più utilizzato), è sembrato logico prendere le specifiche di come lavorasse e, sulla base di quelle, costruire uno standard che, tendenzialmente, permetterà l’adozione dalla maggior parte dei sistemi di gestione di container senza grosse modifiche.

Ovviamente Docker non può che essere contenta del fatto che la sua implementazione è diventata lo standard, come affermato da Michael Crosby, ingegnere e maintainer in Docker:

Docker’s contribution of the Docker Registry V2 specification aligns with our history of making key open-source projects available to the community. As with the runtime and image specification, Docker’s registry protocol has become a de facto standard with over 40 billion images pulled using this protocol.

Il contributo di Docker alle specifiche del Docker Registry V2 si allinea con la nostra abitudine storica di rendere i progetti open-source chiave disponibili alla community. Insieme al runtime ed alle specifiche delle immagini, il registry protocol di Docker è diventato lo standard de facto con oltre 40 miliardi di immagini scaricate usando questo protocollo.

La notizia in ogni caso è stata accolta molto positivamente da tutti, sia da Amazon con il suo Amazon Elastic Container Registry (che comunque è compatibile con il Docker Registry V2), sia da Microsoft che eroga l’Azure Container Registry (implementato usando proprio il Docker Registry) che Google, fornitore di Google Cloud (di cui non si sa molto riguardo il funzionamento dei registry forniti).

Tutti contenti dunque, abbiamo uno standard completo!
Ora non resta che aspettare che tutti lo abbraccino.

Solomon Hykes lascia Docker: il saluto del papà dei container.

Facebooktwittergoogle_plusredditlinkedin

Una settimana fa circa il fulmine a ciel sereno: Solomon Hykes abbandona Docker.

Per chi non lo conoscesse, seppure per l’esattezza non abbia inventato i container, sicuramente è stata la persona che più di tutti ha contribuito a renderli popolari ed uno standard de-facto su cui son nate e sono evolute una serie di altre tecnologie come Kubernetes, per citarne una.

Non si può iniziare a parlare del buon Hykes senza condividere il video di 5 minuti in cui, al PyCon 2013, presentò al mondo Docker, un tool che utilizzavano in dotCloud (società francese fondata da Hykes stesso), per gestire comodamente i container Linux:

Se come dotCloud fornivano servizi per la gestione di applicazioni scalabili usando questa “nuova” tecnologia chiamata container, la presentazione di Docker cambiò il target: finalmente un semplice tool poteva gestire tutto dal network al filesystem, dai namespace dei processi ai cgroup per la gestione delle risorse. Questo fece esplodere il fenomeno al punto che, 5 anni fa, dotCloud cambiò nome come Docker.

Il buon Hykes, che ai tempi era il CEO di dotCloud, insieme alle altre 5 persone al lavoro, decise di assumere un nuovo CEO per Docker in grado di sostenere l’azienda e con esperienza nel ruolo, e si ritagliò il ruolo di CTO (Chief Tecnical Officer). E tutto ha continuato a crescere.

Ora la situazione si è nuovamente evoluta: con la crescita della base clienti di Docker (soprattutto della sua Docker Enterprise Edition), ed in generale della società, si è reso fondamentale trovare un nuovo CTO con l’esperienza necessaria sia al lavoro in team con Steve Singh (attuale CEO), che nella gestione tecnologica della società stessa. E così il ruolo di Hykes cambierà ancora: in un primo momento aiuterà a trovare il CTO ideale al compito e successivamente fornirà la consulenza allo stesso per capire come collaborare al meglio con il team tecnico già presente in azienda.

Sicuramente un ruolo che gli permetterà di mantenere un piede in Docker, lasciandogli però il tempo di continuare a lavorare su altro e chissà, magari, cambiare il mondo dell’IT un’altra volta.

Vi lasciamo al post ufficiale di Hykes sul blog, in cui spiega bene -seppur con un pochino di amarezza- i vari passaggi che l’hanno portato dove è adesso.