Nell’ultimo decennio, i container sono diventati le fondamenta di un numero crescente di ambienti di produzione. Questo cambiamento riflette la modularizzazione dell’approccio DevOps, che consente agli sviluppatori di modificare singole funzionalità senza impattare sull’intera applicazione. I container promettono un metodo semplificato, facile da distribuire e sicuro per implementare specifici requisiti infrastrutturali e rappresentano un’alternativa leggera alle macchine virtuali (VM). Un aspetto spesso sottovalutato, però, è la sicurezza dei cloud container.
Indice degli argomenti
Come funzionano i cloud container?
Le radici della tecnologia dei container affondano nei meccanismi di partizionamento e di isolamento dei processi chroot, sviluppati come parte di Linux. I container moderni si declinano attraverso la containerizzazione delle applicazioni, come Docker, e la containerizzazione di sistema, come i Linux Containers (LXC). Entrambi consentono ai team IT di astrarre il codice applicativo dall’infrastruttura sottostante, semplificando la gestione delle versioni e abilitando la portabilità tra diversi ambienti di deployment.
I container si basano sull’isolamento virtuale per distribuire ed eseguire applicazioni che accedono a un kernel del sistema operativo condiviso, senza la necessità di utilizzare VM. Poiché contengono tutti i componenti necessari – file, librerie e altre dipendenze necessarie per l’esecuzione- i container eseguono il software desiderato senza doversi preoccupare della compatibilità di piattaforma. Il sistema operativo host limita l’accesso del container alle risorse fisiche, impedendo che un singolo container possa consumare tutte le risorse disponibili sul server.
Un aspetto chiave da comprendere dei cloud container è che sono progettati per virtualizzare una singola applicazione. Si consideri, ad esempio, un container MySQL: fornisce un’istanza virtuale di quell’applicazione e null’altro.
I container creano un confine di isolamento a livello applicativo e non a livello di server. Se qualcosa va storto all’interno di un singolo container (ad esempio un consumo eccessivo di risorse da parte di un processo) l’impatto rimane confinato a quel container specifico, senza coinvolgere l’intera VM o il server nel suo complesso. Inoltre, vengono eliminati i problemi di compatibilità tra applicazioni containerizzate che risiedono sullo stesso sistema operativo.
I principali provider cloud offrono i container come servizio, ad esempio Amazon Elastic Container Service, AWS Fargate, Google Kubernetes Engine, Microsoft Azure Container Instances, Azure Kubernetes Service e Oracle Cloud Infrastructure Kubernetes Engine. I container possono anche essere distribuiti su infrastrutture cloud pubbliche o private senza ricorrere a prodotti dedicati di un singolo vendor cloud.
I container vengono distribuiti in due modi: creando un’immagine da eseguire in un container, oppure scaricando un’immagine preconfigurata, come quelle disponibili su Docker Hub. Docker (originariamente costruito su LXC) è di gran lunga la piattaforma di container più diffusa e utilizzata. E sebbene esistano alternative, Docker è diventato di fatto sinonimo di containerizzazione.
Use case dei cloud container
Le imprese utilizzano i container in diversi modi per ridurre i costi e migliorare l’affidabilità del software. Tra i casi d’uso più comuni e vantaggiosi rientrano i seguenti:
Architettura a microservizi. I container sono ideali per lo sviluppo di applicazioni basate su microservizi, in cui le applicazioni vengono suddivise in servizi più piccoli e distribuibili in modo indipendente. Questo migliora la scalabilità e semplifica i cicli di sviluppo. Kubernetes orchestra il deployment, la scalabilità e la gestione di questi servizi, consentendo alle aziende di rilasciare aggiornamenti con tempi di inattività minimi.
Deployment ibridi e multi-cloud. I container abilitano una portabilità cloud-agnostic, permettendo alle imprese di eseguire gli stessi workload su AWS, Azure, Google Cloud Platform o on-premise senza modifiche applicative. Questo supporta strategie di disaster recovery, ottimizzazione dei costi e neutralità rispetto ai vendor.
DevOps e automazione CI/CD. Le aziende utilizzano i container nelle pipeline di continuous integration/continuous delivery (CI/CD) per garantire coerenza dallo sviluppo alla produzione. I container consentono agli sviluppatori di testare in ambienti isolati che replicano la produzione, riducendo i bug e semplificando i flussi di integrazione e distribuzione.
Modernizzazione delle applicazioni legacy. Molte organizzazioni usano i container per modernizzare applicazioni monolitiche legacy in servizi più agili e manutenibili. Containerizzando le applicazioni esistenti, è possibile aggiornare l’infrastruttura in modo incrementale, senza riscritture complete.
Edge e IoT. I container possono essere distribuiti all’edge per casi d’uso come IoT, manifattura e retail. Runtime container come K3s (una versione leggera di Kubernetes) aiutano i team IT a supportare l’orchestrazione all’edge anche in presenza di risorse limitate.
Sicurezza ed enforcement delle policy. Attraverso la containerizzazione delle applicazioni, le imprese possono applicare policy as code utilizzando servizi come Open Policy Agent e gestire la sicurezza a runtime tramite integrazioni con piattaforme di Cloud Workload Protection Platform (CWPP) e strumenti di Cloud-Native Application Protection Platform (CNAPP).
Cloud container vs VM. Rispetto alle virtual machine, i container richiedono molte meno risorse. A differenza delle macchine virtuali, non richiedono l’installazione di un intero sistema operativo all’interno del container, né una copia virtuale dell’hardware del server host.
I container necessitano solo delle risorse strettamente indispensabili per svolgere il compito per cui sono stati progettati, ovvero pochi componenti software, librerie e le funzionalità essenziali del sistema operativo. Di conseguenza, le aziende possono distribuire da due a tre volte più container su un singolo server rispetto alle VM, e possono essere avviati molto più rapidamente.
Vantaggi dei container
I cloud container sono portabili. Una volta creato un container, può essere facilmente distribuito su server differenti. Dal punto di vista del ciclo di vita del software, questo consente alle imprese di copiare rapidamente i container per creare ambienti di sviluppo, test, integrazione e produzione. Dal punto di vista dei test software e di sicurezza, ciò garantisce che il sistema operativo sottostante non influisca sui risultati delle verifiche.
I container offrono inoltre un ambiente più dinamico. L’IT può scalare rapidamente verso l’alto o verso il basso in base alla domanda, mantenendo sotto controllo l’utilizzo delle risorse.
Sfide dei container
Uno degli svantaggi dei container è la frammentazione della virtualizzazione in molte unità più piccole. Quando il numero di container è limitato, questo rappresenta un vantaggio, perché il team sa esattamente quale configurazione sta distribuendo e dove. Se però l’organizzazione investe massicciamente nei container, è possibile arrivare a gestirne così tanti da renderne complessa l’amministrazione. Si pensi, ad esempio, alla distribuzione di patch su centinaia di container diversi. Senza un processo semplice ed efficace, aggiornare una specifica libreria o un pacchetto all’interno di un’immagine container a causa di una vulnerabilità di sicurezza può diventare complicato.
La gestione dei container è spesso un problema, anche utilizzando sistemi come Docker, progettati per semplificare l’orchestrazione per l’IT.
Rischi di sicurezza dei cloud container
Sebbene i container offrano numerosi vantaggi, introducono anche rischi di sicurezza specifici che le imprese devono affrontare. La natura dinamica dei container richiede un approccio moderno alla sicurezza, proattivo, automatizzato e integrato nei flussi DevOps. Di seguito sono riportati alcuni dei principali rischi che le organizzazioni dovrebbero considerare prioritari:
Immagini vulnerabili. I container vengono creati a partire da immagini che spesso includono librerie di sistema, dipendenze runtime e codice personalizzato. Molte aziende utilizzano immagini base pubbliche provenienti da registry come Docker Hub, che potrebbero contenere vulnerabilità non corrette o malware. È necessario scansionare continuamente le immagini, utilizzare fonti firmate e verificate e definire allowlist di immagini per garantire la sicurezza di tutte le build.
Container escape. I container sono isolati, ma non impenetrabili. Un container breakout si verifica quando un attore malevolo riesce a uscire dal runtime del container e ad accedere al sistema operativo host. Il rischio aumenta se i container vengono eseguiti con privilegi elevati o con permessi di root. Le contromisure includono l’esecuzione dei container come utenti non root, l’uso di moduli di sicurezza del kernel come AppArmor e SELinux e l’adozione di runtime sandboxed come gVisor o Kata Containers. Nei contesti cloud, alcune di queste mitigazioni possono risultare difficili o impossibili a causa della limitata capacità di controllo e configurazione da parte del cliente.
Esposizione di credenziali. Memorizzare credenziali, chiavi API o token all’interno dei container o nelle variabili d’ambiente comporta rischi significativi. In caso di compromissione, un attaccante potrebbe ottenere accesso a database, risorse cloud o servizi interni. Le best practice prevedono l’uso di strumenti di gestione dedicati, come HashiCorp Vault o AWS Secrets Manager, ed evitare segreti hardcoded nelle immagini o nei repository Git.
Attacchi alla supply chain. I container fanno parte di una supply chain software più ampia che comprende codice, immagini, pipeline, registry e strumenti CI/CD. Gli attaccanti possono sfruttare vulnerabilità in questa catena per iniettare codice malevolo o compromettere i deployment. La mitigazione richiede l’applicazione della firma del codice e dell’integrità delle immagini, l’uso ove possibile di software bill of materials (SBOM) per tracciare le dipendenze e il monitoraggio delle anomalie nelle pipeline di build.
Minacce in fase di runtime. Una volta distribuiti, i container restano esposti ad attacchi, tra cui reverse shell, malware di cryptomining e movimenti laterali all’interno dei cluster Kubernetes. I team di sicurezza dovrebbero adottare strumenti di protezione a runtime — funzionalità prioritarie per la maggior parte delle piattaforme CNAPP e CWPP — per monitorare chiamate di sistema, comportamento dei container e traffico di rete, al fine di rilevare e bloccare le minacce in tempo reale.
Orchestrazione configurata in modo errato. Le misconfiguration di Kubernetes o di altri orchestrator rappresentano uno dei principali rischi per la sicurezza dei container. Errori comuni includono l’esposizione su Internet di dashboard e API Kubernetes, l’uso di impostazioni di autenticazione predefinite o deboli e l’assegnazione di ruoli di cluster troppo ampi ai service account.
Segmentazione di rete. I container comunicano spesso tra loro all’interno di reti virtuali di cluster. In assenza di policy di rete adeguate, un container compromesso potrebbe facilitare movimenti laterali da parte di un attaccante. È fondamentale applicare il principio del minimo privilegio utilizzando le network policy di Kubernetes, soluzioni come Calico o service mesh come Istio per limitare la connettività.
Best practice per la sicurezza dei cloud container
Con la diffusione dei cloud container, l’attenzione si è spostata su come mantenerli sicuri. È opportuno considerare quanto segue:
Impostare correttamente i privilegi di accesso. In passato, i container Docker dovevano essere eseguiti come utenti privilegiati sul sistema operativo sottostante. Se parti critiche del container venivano compromesse, potenzialmente si poteva ottenere accesso root o amministrativo anche sull’OS host, o viceversa. Oggi Docker supporta lo user namespace, che consente al container di essere eseguito come utenti specifici.
Distribuire container rootless. Questi container aggiungono un ulteriore livello di sicurezza perché non richiedono privilegi di root. Di conseguenza, se un container rootless viene compromesso, l’attaccante non ottiene accesso root. Un ulteriore vantaggio è la possibilità per utenti diversi di eseguire container sullo stesso endpoint. Attualmente Docker supporta i container rootless, mentre Kubernetes no.
Prestare attenzione alla sicurezza delle immagini. È fondamentale valutare la sicurezza delle immagini scaricate da repository pubblici come Docker Hub. Scaricando un’immagine sviluppata dalla community, la sicurezza del container non può essere garantita a priori. Le immagini possono essere sottoposte a scansioni per individuare vulnerabilità, offrendo un certo livello di garanzia; tuttavia, tali processi di verifica potrebbero non essere sufficientemente approfonditi per applicazioni particolarmente sensibili. In questi casi, è consigliabile creare le immagini internamente, assicurandosi che le policy di sicurezza vengano applicate e che gli aggiornamenti siano regolari. Va comunque ricordato che le immagini aziendali sono sicure solo quanto lo sono le pratiche adottate dai dipendenti: una formazione adeguata di chi crea le immagini è fondamentale.
Monitorare i container. Se un container inizia a comportarsi in modo anomalo o a consumare più risorse del necessario, è semplice arrestarlo e riavviarlo. Non si tratta di una sandbox vera e propria, ma i container offrono un modo per mantenere separate applicazioni non affidabili.
Dare priorità a minacce e vulnerabilità. Un deployment e una gestione corretti sono elementi chiave. I container dovrebbero essere sottoposti a scansioni regolari per garantire che immagini e container attivi restino aggiornati e sicuri.
Non dimenticare la sicurezza del server che ospita i container. Se l’organizzazione utilizza un provider di cloud container, è quest’ultimo a essere responsabile dell’operatività, del patching e dell’hardening del servizio.
