- La sicurezza dei container Docker comprende host, immagini, rete, segreti e orchestrazione, non solo il container stesso.
- I rischi maggiori derivano da immagini vulnerabili, configurazioni non sicure, privilegi eccessivi e una cattiva gestione dei segreti.
- Buone pratiche come l'uso di immagini minimaliste, la limitazione delle capacità, la segmentazione delle reti e il monitoraggio in tempo reale riducono drasticamente la superficie di attacco.
- L'integrazione di scansioni e policy di sicurezza nella pipeline CI/CD e l'utilizzo di strumenti specializzati consentono di aumentare la sicurezza senza rallentare DevOps.
Docker ha cambiato per sempre il modo in cui sviluppiamo e distribuiamo le applicazioni : impacchettare codice, librerie e configurazione in un container e spostarlo dal proprio laptop all'ambiente di produzione senza sorprese è quasi magia ( cos'è Docker ). Ma questa magia ha un rovescio della medaglia: se trascuriamo la sicurezza, un singolo container configurato in modo errato può fungere da porta d'accesso all'intera infrastruttura.
Molti team si affidano ancora ciecamente all'isolamento dei container e all'orchestrazione di Kubernetes (vedi Docker Compose e Kubernetes ) come se fossero una cassaforte sicura, quando in realtà stiamo parlando di processi che condividono kernel, reti e, in troppi casi, permessi eccessivi. Analizziamo nel dettaglio perché la sicurezza dei container Docker è un pilastro fondamentale, quali sono i rischi reali e quali tecniche e strumenti vengono attualmente utilizzati in produzione per mitigarli senza sacrificare l'agilità DevOps.
Cos'è esattamente la sicurezza dei container Docker?
Quando parliamo di sicurezza dei container Docker, ci riferiamo all'insieme di pratiche, configurazioni e strumenti che proteggono i container, l'host, la rete e la catena di fornitura del software stessa da vulnerabilità, configurazioni errate e attacchi attivi. Non si tratta solo di "mantenere un'immagine professionale", ma di proteggere l'intero ciclo di vita: dalla creazione alla pubblicazione, al deployment e all'esecuzione.
La principale difficoltà con i container risiede nella condivisione del kernel del sistema operativo host ( namespace e cgroup in Linux ). Ciò significa che una vulnerabilità a livello di kernel o una fuga di un container non adeguatamente protetta possono avere un impatto su tutti i container presenti sul nodo. La sicurezza di Docker, pertanto, non riguarda solo l'aspetto esteriore: implica il rafforzamento dell'host, la limitazione dei privilegi, la segmentazione delle reti, il controllo di chi comunica con l'API del demone e la gestione delle informazioni riservate.
Un altro aspetto fondamentale è la sicurezza e l'orchestrazione dei processi : come vengono eseguiti i container, con quale utente, quali funzionalità del kernel possiedono, quali risorse possono consumare e quali policy vengono applicate in un cluster Kubernetes. Ciò include concetti come il principio del minimo privilegio, i profili di sicurezza (seccomp, AppArmor, SELinux) e il controllo degli accessi basato sui ruoli (RBAC).
Rischi e problemi di sicurezza comuni in Docker
Gli incidenti negli ambienti containerizzati derivano in genere da una combinazione di errore umano e decisioni tecniche errate . Di seguito sono elencati i problemi più comuni identificati negli audit e nelle violazioni reali.
Immagini vulnerabili o dannose
Ogni immagine container è un piccolo sistema con il proprio set di pacchetti e dipendenze ; se si scarica un'immagine obsoleta, pesante o di dubbia provenienza, si ereditano anche le relative vulnerabilità (CVE), backdoor e pratiche scorrette. Le scansioni di milioni di immagini pubbliche hanno dimostrato che una parte significativa contiene malware o vulnerabilità critiche note.
Il problema si aggrava quando intere distribuzioni (Ubuntu, Debian, ecc.) vengono utilizzate come base per applicazioni che richiedono solo poche librerie. Quelle centinaia di pacchetti aggiuntivi (editor, shell, gestori di pacchetti, strumenti di rete, ecc.) espandono la superficie di attacco senza aggiungere alcun valore in produzione. Per un malintenzionato che riesce ad ottenere l'accesso, trovare uno script apt-get o curl pronto a scaricare malware è un vero e proprio regalo.
Fuga dai contenitori all'host
Una fuga da un container si verifica quando un attaccante riesce a uscire dalla sandbox del container ed eseguire azioni sul sistema host o su altri container. In genere, ciò comporta lo sfruttamento di vulnerabilità del kernel, configurazioni non sicure (come volumi con accesso eccessivo) o container in esecuzione con privilegi eccessivi.
Se il container compromesso viene eseguito come root con ampi privilegi , l'attacco all'host o al resto dell'infrastruttura risulta molto più semplice. Da qui la continua enfasi sul non utilizzare `--privileged` , sul limitare le funzionalità del kernel e sull'eseguire i processi con utenti non privilegiati, sia all'interno che all'esterno del container (namespace utente, senza privilegi di root, ecc.).
Configurazioni di rete non sicure
La rete è un altro ambito in cui Docker e Kubernetes spesso commettono errori : le porte vengono pubblicate con noncuranza, si fa un uso superfluo di --network=host , non esistono policy di rete nel cluster o i container comunicano tra loro senza restrizioni.
Quando tutti i container possono comunicare liberamente , un attaccante che compromette un microservizio può spostarsi lateralmente verso database, code di messaggi o dashboard interne. Inoltre, l'esposizione accidentale di servizi di gestione o API interne è una causa ricorrente di incidenti.
Daemon Docker esposto o scarsamente protetto
Il demone Docker è il "cervello" che gestisce la creazione, la distruzione e il controllo dei container . Se la sua API è accessibile senza crittografia o autenticazione, chiunque vi acceda può eseguire container arbitrari, montare volumi host, leggere informazioni riservate o persino eliminare l'intera infrastruttura.
Proteggere il socket del demone e la sua API è fondamentale : utilizzare TLS, limitare l'accesso al socket Unix, non esporre l'endpoint TCP se non strettamente necessario e verificarne regolarmente la configurazione sono misure di base per evitare di cedere il controllo della piattaforma.
Segreti e variabili ambientali svelati
Un errore classico negli ambienti container è quello di lasciare credenziali e chiavi API dove non dovrebbero : incorporate nei Dockerfile, all'interno dell'immagine stessa, in semplici variabili d'ambiente o addirittura caricate accidentalmente nel sistema di controllo versione.
Una volta che un segreto viene incorporato in un'immagine , chiunque abbia accesso al registro o al container stesso può recuperarlo con un semplice comando di ispezione. Questo include password di database, token di servizi esterni o chiavi di accesso al cloud: il tipo di informazioni che sicuramente non si desidera finiscano nelle mani di un malintenzionato.
Vulnerabilità del kernel e dell'host
Poiché tutti i container condividono lo stesso kernel, qualsiasi vulnerabilità a quel livello ha un impatto sull'intero sistema ( monitor di sistema avanzato per Linux ). Se il sistema host non è aggiornato o utilizza kernel più vecchi e non supportati, la probabilità di una vulnerabilità sfruttabile pubblicamente aumenta drasticamente.
Oltre al kernel, anche la configurazione del sistema operativo host (cgroup, namespace, moduli caricati, servizi non necessari) influisce direttamente sul rischio. Un host configurato in modo inadeguato rende inefficace l'isolamento logico dei container.
Mancanza di visibilità e monitoraggio
Senza un buon sistema di registrazione degli eventi e un monitoraggio in tempo reale, un attacco può rimanere attivo per settimane senza che nessuno se ne accorga. Gli strumenti di sicurezza tradizionali (ad esempio, cos'è Wazuh? ) spesso non riescono a rilevare cosa accade all'interno di un container o non lo collegano al contesto di Kubernetes.
Una visibilità granulare a livello di container e pod (processi, connessioni di rete, modifiche al file system, consumo di risorse) è essenziale per rilevare comportamenti anomali, indicatori di compromissione e movimenti laterali.
Procedure consigliate prima di distribuire i container Docker
La sicurezza di Docker inizia ben prima che il container raggiunga l'ambiente di produzione . Dalla selezione dell'host al Dockerfile, ogni decisione contribuisce ad aumentare o diminuire la superficie di attacco.
Rafforzare il sistema host
Il primo passo consiste nell'avere un sistema operativo host pulito e aggiornato, dedicato esclusivamente ai container (consultare la guida per la configurazione e la gestione di un server Ubuntu ). Minore è la condivisione del nodo con altre applicazioni legacy, minore sarà la probabilità che un guasto in un altro servizio influisca sui carichi di lavoro containerizzati.
Aggiornare tempestivamente il kernel e scegliere versioni LTS con supporto attivo riduce drasticamente il rischio che un exploit noto venga utilizzato per aggirare l'isolamento. Inoltre, abilitare e configurare correttamente meccanismi come AppArmor, SELinux e cgroups contribuisce a limitare le azioni che un processo compromesso può compiere.
Scegli immagini ufficiali e minimaliste
L'utilizzo di immagini ufficiali e verificate come base dovrebbe essere la norma . Repository come Docker Hub segnalano gli editori verificati e molte aziende mantengono registri privati con le proprie immagini protette, soggette a continue scansioni e revisioni.
Quando possibile, è consigliabile scegliere immagini "slim", Alpine o addirittura senza distro , che includano solo le dipendenze strettamente necessarie. Ridurre il numero di pacchetti utente e strumenti interattivi minimizza il numero di potenziali vulnerabilità, velocizza il deployment e rende molto più difficile per un aggressore ottenere l'esecuzione di codice all'interno del container.
Crea Dockerfile tenendo presente la sicurezza
Il Dockerfile è lo script che definisce tutto ciò che viene eseguito all'interno del container , quindi è consigliabile scriverlo con un approccio orientato alla sicurezza: rimuovere gli strumenti di debug dall'ambiente di produzione, non lasciare tracce delle credenziali, impostare versioni specifiche dei pacchetti, pulire le cache del gestore di pacchetti e separare le fasi di compilazione ed esecuzione in più livelli (build multi-stage).
Un altro passaggio cruciale è definire un utente non privilegiato all'interno del Dockerfile e modificare il contesto di esecuzione con il comando `USER` . Non avviare mai i servizi come root all'interno del container "perché è più semplice"; non appena emerge una vulnerabilità di sicurezza, questa comodità si trasformerà in un enorme problema.
Scansione sistematica delle immagini
La scansione delle immagini alla ricerca di vulnerabilità note prima della loro registrazione dovrebbe essere obbligatoria . Strumenti come Trivy, Clair, Anchore, Snyk Container o le funzionalità di Docker Scout consentono di analizzare sia le immagini di base che le build personalizzate.
L'integrazione di questi scanner nella pipeline CI/CD impedisce che un'immagine con CVE critiche venga distribuita in produzione "perché ci siamo dimenticati di controllarla". Idealmente, dovrebbero essere definite politiche chiare: ad esempio, bloccare la distribuzione in presenza di vulnerabilità di alto livello o critiche senza una patch disponibile o una giustificazione documentata.
Gestione sicura dei segreti e della configurazione
La gestione della riservatezza è uno dei tipici punti deboli dei container . Avere un'immagine perfetta è inutile se password e chiavi sono incorporate in chiaro al loro interno.
La regola d'oro è che i segreti non dovrebbero mai far parte dell'immagine : non scrivere mai le credenziali nel Dockerfile, né copiarle come file all'interno del container. È preferibile utilizzare meccanismi di iniezione a runtime: Docker Secrets (in Swarm), gestori esterni come HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o altri servizi equivalenti.
Se si utilizzano variabili d'ambiente, è necessario gestirle con estrema cautela : evitare di scriverle nei log, non caricare file con valori reali nei repository di codice, verificare quali comandi diagnostici potrebbero visualizzare valori sensibili e ruotare frequentemente le chiavi. Crittografare i dati a riposo e applicare controlli di accesso rigorosi (chi può leggere cosa) preclude molte possibilità di accesso.
Rete, controllo degli accessi e applicazione rafforzata
Una volta che le immagini e l'host sono sotto controllo, è necessario considerare come si connettono, chi può avviarle e cosa possono fare in fase di esecuzione . È qui che entrano in gioco la rete, il controllo degli accessi basato sui ruoli (RBAC), le funzionalità del kernel, le quote di risorse e gli strumenti di monitoraggio.
Progettazione e segmentazione della rete
In Docker, si consiglia di utilizzare reti personalizzate ed evitare di pubblicare le porte esternamente, a meno che non sia assolutamente necessario . Definire reti bridge o overlay specifiche per l'applicazione o il dominio funzionale contribuisce a mitigare potenziali rischi (vedere l'architettura a microservizi ).
Negli ambienti orchestrati da Kubernetes, le Network Policies sono essenziali : consentono di definire quali pod possono comunicare tra loro e su quali porte. Di default, molti cluster consentono una comunicazione illimitata tra i pod, il che è comodo all'inizio ma disastroso in caso di intrusione. L'integrazione di firewall di livello 7 e TLS nelle comunicazioni tra i servizi aggiunge un ulteriore livello di protezione.
Controllo degli accessi, autenticazione e firma delle immagini
L'accesso ai registri, all'API di Docker e al piano di controllo di Kubernetes dovrebbe sempre richiedere un'autenticazione forte e un controllo dei permessi . Non tutti hanno bisogno di poter caricare immagini o effettuare il deployment in produzione.
I meccanismi di Docker Content Trust e di firma delle immagini garantiscono che vengano utilizzate solo immagini firmate da entità attendibili. Parallelamente, il controllo degli accessi basato sui ruoli (RBAC) sia in Kubernetes che nella piattaforma CI/CD stessa controlla chi può avviare, scalare, modificare o eliminare container e risorse associate.
Esegui i contenitori con i privilegi più bassi possibili
Evitate di usare container con `--privileged` perché altrimenti non funzioneranno . Questo flag concede praticamente l'accesso completo all'host e rimuove molte misure di isolamento. L'approccio corretto è avviare i servizi con `--cap-drop=ALL` e quindi aggiungere solo le funzionalità del kernel necessarie all'applicazione (ad esempio, `NET_BIND_SERVICE` per l'ascolto su porte basse).
È inoltre importante utilizzare file system di sola lettura ogni volta che è possibile ( `--read-only` ) e montare volumi specifici per i dati che devono essere persistenti. Questo rende più difficile per un utente malintenzionato scrivere file binari dannosi o modificare le configurazioni all'interno del container. Limitare la creazione di nuovi processi e disabilitare l'escalation dei privilegi completano la protezione.
Profili di sicurezza del kernel: seccomp, AppArmor e SELinux
Docker include già un profilo seccomp predefinito che filtra le chiamate di sistema considerate pericolose , ma in molti casi è consigliabile adattare o creare profili specifici per ogni tipo di carico di lavoro. Minore è il numero di chiamate di sistema esposte da un processo, minore è la possibilità di un exploit.
In distribuzioni come Ubuntu e RHEL, AppArmor e SELinux aggiungono un ulteriore livello di controllo su ciò che ogni container può fare: accesso a file, dispositivi, reti, ecc. Se configurati correttamente, questi meccanismi di controllo degli accessi obbligatori rendono molto più difficile il successo di un attacco, anche se sfrutta una vulnerabilità nell'applicazione.
Quote di risorse e tutela contro gli abusi
Configurare i limiti di CPU, memoria e, se applicabile, I/O per ciascun container non solo migliora le prestazioni del cluster, ma limita anche l'impatto di attacchi che tentano di esaurire le risorse (DoS dall'interno) o di bug che causano perdite di memoria.
I cgroup consentono di definire queste quote con notevole precisione e rappresentano un complemento naturale ad altre misure di sicurezza. Un attaccante che tentasse di minare criptovalute all'interno di un container con limiti rigorosi troverà molto più difficile compromettere gli altri servizi sull'host.
Monitoraggio, risposta agli incidenti e strumenti specializzati
Sarebbe un errore concludere il quadro della sicurezza dei container senza parlare del monitoraggio . La realtà è che prima o poi emergeranno nuove vulnerabilità, errori umani o comportamenti inattesi; la differenza sta nella rapidità con cui li si individua e nella capacità di reagire.
Centralizzare i log di container, host, orchestrazione e registro consente di correlare gli eventi e identificare modelli che sfuggirebbero se ogni elemento fosse analizzato separatamente. Soluzioni come ELK, Grafana Loki o i servizi cloud gestiti sono comunemente utilizzate a questo scopo.
Nell'ambito del rilevamento delle minacce in fase di esecuzione, Falco è diventato di fatto uno standard open-source . Analizza le chiamate di sistema e genera avvisi quando rileva attività sospette: shell interattive in container che non dovrebbero averle, scritture su percorsi sensibili, connessioni di rete insolite e così via. Integrato con strumenti SIEM o piattaforme di risposta, consente una risposta rapida.
Per una copertura più ampia e completa del ciclo di vita, esistono piattaforme di sicurezza native del cloud come Aqua Security, Prisma Cloud, Sysdig Secure, Qualys Container Security, oppure suite unificate pensate per gli sviluppatori come Aikido Security. Queste soluzioni combinano la scansione delle immagini, la sicurezza in fase di esecuzione, la gestione della postura nel cloud, l'analisi del codice, il rilevamento di segreti, la generazione di SBOM e molto altro.
Il valore aggiunto di queste piattaforme risiede solitamente nel consolidamento dei risultati e nella prioritizzazione intelligente : invece di inondare i team con migliaia di avvisi, evidenziano le vulnerabilità effettivamente sfruttabili nel loro ambiente, offrono chiare guide per la risoluzione e suggeriscono persino patch tramite intelligenza artificiale, in modo che gli sviluppatori possano correggerle più rapidamente.
Automazione della sicurezza nella pipeline CI/CD
Gestire manualmente la sicurezza dei container è una ricetta per sviste e vulnerabilità . Per questo motivo, uno dei consigli più frequenti è quello di integrare tutti i controlli possibili nella pipeline CI/CD: prima vengono rilevati i problemi, minore sarà il costo per risolverli.
Idealmente, ogni modifica al codice dovrebbe innescare una catena automatica di processi : creazione dell'immagine, scansione delle vulnerabilità, analisi delle dipendenze, revisione dei file di infrastruttura come codice, controlli delle policy (ad esempio, che nessun container venga eseguito come root) e, solo se tutto ha esito positivo, caricamento nel registro e distribuzione.
Questo approccio riduce notevolmente la dipendenza dalla memoria o dalla disciplina individuale . Se il sistema impedisce il deployment di un'immagine con vulnerabilità critiche o una configurazione che viola le policy, è molto più difficile che qualcosa di inaccettabile si insinui in produzione "di fretta". Inoltre, l'automazione della rotazione delle immagini e del frequente re-deployment contribuisce a mantenere sempre versioni aggiornate, impedendo ai pod di funzionare con software obsoleto per mesi.
Nelle organizzazioni con team multipli e decine di microservizi , disporre di una piattaforma centralizzata che consolidi le informazioni sulla sicurezza (codice, container, cloud, dipendenze) e fornisca una visione chiara del rischio per progetto semplifica notevolmente il lavoro dei responsabili della sicurezza e dei leader tecnici.
In definitiva, la sicurezza dei container Docker e dei cluster Kubernetes non dipende da un singolo componente o strumento , ma piuttosto da una combinazione di buone pratiche di gestione delle immagini, un host aggiornato, reti segmentate, principio del minimo privilegio, gestione rigorosa dei segreti, monitoraggio continuo e una solida automazione delle pipeline. Rendere queste pratiche una routine quotidiana, anziché limitarsi a progetti una tantum, è ciò che fa la differenza tra un ambiente che "funziona finché non succede qualcosa" e una piattaforma preparata a gestire gli incidenti senza compromettere l'attività aziendale.
