Quando Tesla ha scoperto che nel 2018 alcuni hacker stavano eseguendo operazioni di cryptomining all'interno dei suoi cluster Kubernetes, la causa principale era sorprendentemente semplice: una dashboard esposta senza password. Anni dopo, lo stesso tipo di configurazione errata continua ad affliggere le organizzazioni su larga scala. Il 90% delle organizzazioni ha subito almeno un incidente di sicurezza Kubernetes negli ultimi 12 mesi (Red Hat 2024) e i nuovi cluster subiscono il loro primo tentativo di attacco entro 18 minuti dall'implementazione (Wiz 2025). Con una crescita prevista del mercato della sicurezza dei container e di Kubernetes da 1,7 miliardi di dollari nel 2024 a 8-9 miliardi di dollari entro il 2030-2033, l'urgenza di proteggere questi ambienti non è mai stata così grande. Questa guida copre l'intero spettro della sicurezza di Kubernetes, dai modelli di base e dalle best practice del ciclo di vita al rilevamento delle minacce comportamentali e alle strategie cloud che affrontano gli attacchi più sofisticati di oggi.
La sicurezza Kubernetes è l'insieme di pratiche, strumenti e politiche che proteggono i carichi di lavoro containerizzati e la loro infrastruttura di orchestrazione durante l'intero ciclo di vita dell'applicazione, dalla creazione dell'immagine alla distribuzione e al funzionamento in fase di esecuzione. Comprende il rafforzamento della configurazione, il controllo degli accessi (RBAC), la segmentazione della rete, la gestione dei segreti, il rilevamento delle minacce in fase di esecuzione e il monitoraggio della conformità su tutto il piano di controllo, i nodi di lavoro, le immagini dei container, il traffico di rete e i livelli di configurazione.
Perché è importante? Kubernetes non è sicuro per impostazione predefinita. Nella sua configurazione predefinita, la piattaforma privilegia la flessibilità e la velocità degli sviluppatori rispetto alla sicurezza rafforzata. Le organizzazioni devono configurare attivamente il controllo degli accessi basato sui ruoli (RBAC), le politiche di rete, la crittografia dei segreti, gli standard di sicurezza dei pod e la registrazione degli audit prima che un cluster sia pronto per la produzione. Secondo la documentazione sui concetti di sicurezza di Kubernetes, il modello di responsabilità condivisa attribuisce la responsabilità della configurazione della sicurezza direttamente all'operatore.
Le conseguenze negative di un errore in questo ambito sono gravi. Il 67% delle organizzazioni ha ritardato o rallentato le implementazioni a causa di problemi di sicurezza relativi a Kubernetes, il 46% ha subito perdite di fatturato o di clienti e il 30% è stato multato (Red Hat 2024). La superficie di attacco in espansione di un cluster Kubernetes comprende il server API, l'archivio dati etcd, kubelet, il runtime dei container, la sovrapposizione di rete e ogni carico di lavoro in esecuzione al suo interno.
La sicurezza dei container si concentra sulle singole immagini dei container, sui runtime e sui meccanismi di isolamento. La sicurezza di Kubernetes aggiunge aspetti relativi al livello di orchestrazione che vanno oltre il singolo container. Questi includono i controlli di accesso al server API, le politiche RBAC che regolano chi può fare cosa all'interno del cluster, la comunicazione tra pod e spazi dei nomi regolata dalle politiche di rete, la gestione dei segreti e la crittografia a riposo, i controller di ammissione che convalidano i carichi di lavoro prima della distribuzione e la configurazione a livello di cluster, come la registrazione degli audit e gli standard di sicurezza dei pod.
Un'immagine container hardened distribuita in un cluster configurato in modo errato rimane vulnerabile. La sicurezza di Kubernetes riguarda l'infrastruttura che circonda, collega e orchestra tali container.
Le configurazioni errate sono la causa principale delle violazioni di Kubernetes, ma gli attacchi mirati che utilizzano movimenti laterali e l'escalation dei privilegi stanno aumentando notevolmente. Oltre il 50% degli intervistati nel rapporto Red Hat 2024 ha citato le configurazioni errate come la causa principale degli incidenti di sicurezza di Kubernetes. La ripartizione delle principali preoccupazioni in materia di sicurezza è chiara: vulnerabilità (33%), configurazioni errate ed esposizioni (27%), attacchi attivi (24%) e audit di conformità non superati (16%).
A peggiorare la situazione, l'81% dei cluster EKS continua a fare affidamento sull'autenticazione CONFIG_MAP ormai obsoleta (Wiz 2025), creando un rischio legacy che gli aggressori sfruttano attivamente. Gli attacchi di movimento laterale basati su container sono aumentati del 34% nel 2025 (Tigera), riflettendo un passaggio dallo sfruttamento opportunistico di configurazioni errate a operazioni deliberate post-compromissione.
Questi casi di studio datati e documentati dimostrano le conseguenze di una sicurezza Kubernetes inadeguata e gli insegnamenti che si possono trarre da ciascun incidente.
MITRE ATT&CK fornisce un linguaggio condiviso per mappare le minacce Kubernetes ai controlli di sicurezza. La tabella seguente mappa le tattiche chiave della matriceMITRE ATT&CK a specifici controlli di sicurezza Kubernetes.
Tabella 1: Matrice MITRE ATT&CK mappata sui controlli di sicurezza Kubernetes
Il modello delle 4 C fornisce un framework di difesa a più livelli in cui ogni livello di sicurezza dipende dall'integrità del livello sottostante. Questo modello, ampiamente adottato nel settore, organizza la sicurezza di Kubernetes in quattro livelli annidati.
Ogni livello si basa su quello sottostante. Un'immagine container perfettamente protetta offre una protezione limitata se il cluster in cui viene eseguita consente l'accesso API anonimo. Allo stesso modo, le rigorose configurazioni cloud perdono il loro valore se il codice in esecuzione all'interno dei container contiene segreti hardcoded o dipendenze vulnerabili.
Una sicurezza Kubernetes efficace richiede controlli in ogni fase del ciclo di vita, con il rilevamento in fase di esecuzione che colma le lacune che la scansione in fase di compilazione non è in grado di affrontare. Le seguenti pratiche, organizzate nelle fasi di compilazione, distribuzione ed esecuzione, forniscono una checklist completa per la sicurezza Kubernetes in linea con l'OWASP Kubernetes Security Cheat Sheet.
Un contesto di sicurezza Kubernetes definisce le impostazioni relative ai privilegi e al controllo degli accessi per un pod o un container. Queste impostazioni includono l'esecuzione come utente non root, l'eliminazione delle funzionalità Linux, l'impostazione di file system root di sola lettura e la definizione di profili seccomp. L'applicazione coerente dei contesti di sicurezza a tutti i carichi di lavoro impedisce molti percorsi comuni di escalation dei privilegi.
La sicurezza runtime in Kubernetes consiste nel monitorare e proteggere i carichi di lavoro dopo la loro distribuzione. A differenza della scansione in fase di compilazione, che rileva le vulnerabilità note prima della distribuzione, la sicurezza runtime rileva minacce attive, comportamenti anomali e zero-day nei cluster attivi. Le organizzazioni con iniziative DevSecOps avanzate (42% degli intervistati) integrano la prevenzione in fase di compilazione con il rilevamento runtime (Red Hat 2024).
Lo stack di sicurezza basato su eBPF (Falco, Tetragon, Cilium) sta diventando lo standard per il rilevamento runtime di Kubernetes con un impatto minimo sulle prestazioni. I seguenti strumenti rappresentano le principali opzioni open source nelle categorie di scansione, applicazione delle policy e rilevamento runtime.
Tabella 2: Confronto tra gli strumenti di sicurezza Kubernetes
Kubescape ha raggiunto lo status di CNCF Incubating ed è utilizzato da oltre 25.000 aziende in più di 100.000 cloud (CNCF 2025), diventando il primo scanner di sicurezza Kubernetes accettato nella CNCF.
Extended Berkeley Packet Filter (eBPF) consente l'osservabilità e l'applicazione a livello di kernel con un overhead della CPU inferiore all'1% (Tetragon), trasformando il modo in cui le organizzazioni affrontano la sicurezza runtime di Kubernetes. Gli strumenti chiave basati su eBPF includono:
Lo stack open source consigliato di Kubescape, Falco, Trivy e Cilium offre una scansione e un rilevamento completi della sicurezza di Kubernetes con un overhead totale della CPU compreso tra l'1 e il 2,5%. Questa efficienza rende la sicurezza basata su eBPF praticabile per i carichi di lavoro di produzione in cui i budget prestazionali sono limitati. Per le organizzazioni che desiderano valutare i propri strumenti esistenti, gli strumenti NDR e i sistemi di rilevamento e prevenzione delle intrusioni integrano il rilevamento basato su eBPF con la visibilità a livello di rete.
Il rilevamento comportamentale delle minacce e la visibilità a livello di rete colmano il divario critico tra gli strumenti di sola prevenzione e le minacce attive che prendono di mira i cluster Kubernetes. La scansione delle configurazioni e l'applicazione delle policy sono necessarie ma insufficienti. Esse impediscono configurazioni dannose note, ma non sono in grado di rilevare gli aggressori attivi che hanno aggirato i controlli di prevenzione.
Kubernetes utilizza per impostazione predefinita una rete piatta in cui qualsiasi pod può comunicare con qualsiasi altro pod. Ciò rende fondamentale il rilevamento dei movimenti laterali. Gli aggressori sfruttano questa vulnerabilità spostandosi da un pod all'altro all'interno di uno spazio dei nomi, passando da uno spazio dei nomi all'altro all'interno del cluster e accedendo ai servizi cloud dall'interno dei pod compromessi.
worm TeamPCP worm febbraio 2026) ha dimostrato questo modello su larga scala. Un singolo punto d'appoggio ha consentito al gruppo di enumerare l'intero cluster, eseguire comandi su tutti i carichi di lavoro e distribuire un DaemonSet privilegiato che ha convertito il cluster in una botnet distribuita, compromettendo almeno 185 server (eSecurity Planet). Con gli attacchi di movimento laterale basati su container in aumento del 34% nel 2025, la capacità di rilevare modelli di traffico est-ovest anomali non è più facoltativa.
Il rilevamento comportamentale delle minacce si concentra sull'identificazione di modelli anomali piuttosto che sulla corrispondenza di firme note. Negli ambienti Kubernetes, questi modelli includono chiamate API insolite, comunicazioni pod-to-pod inattese, anomalie nell'accesso alle credenziali e indicatori di dirottamento delle risorse.
La vulnerabilità della telemetria Kubernetes rivelata nel gennaio 2026 illustra perché questo approccio è importante. I ricercatori hanno scoperto che l'autorizzazione GET RBAC dei nodi/proxy, comunemente concessa agli strumenti di monitoraggio, può essere utilizzata in modo improprio per eseguire comandi arbitrari all'interno dei pod tramite l'API Kubelet. Kubernetes ha classificato questo comportamento come "funzionamento previsto" e non rilascerà alcuna patch. L'unica difesa consiste nel rilevare operazioni di esecuzione anomale dagli account dei servizi di monitoraggio (The New Stack), un caso d'uso da manuale per l'analisi comportamentale e la ricerca delle minacce.
I metodi di rilevamento delle minacce Kubernetes includono:
Nessuna guida di alto livello sulla sicurezza di Kubernetes tratta il tema dell'integrazione tra il rilevamento e la risposta di rete (NDR) e la sicurezza di Kubernetes: un punto cieco significativo, dato che la visibilità a livello di rete rileva minacce che gli strumenti basati sulla configurazione non riescono a individuare.
NDR fornisce visibilità sul traffico est-ovest all'interno dei cluster Kubernetes, identificando modelli di comunicazione anomali come pod che raggiungono servizi imprevisti, volumi di dati insoliti tra spazi dei nomi e tentativi di esfiltrazione dei dati attraverso canali laterali. Ciò integra la scansione delle configurazioni e l'applicazione delle politiche con il rilevamento attivo delle minacce a livello di rete, colmando il divario di rilevamento che consente al 90% delle organizzazioni di continuare a subire incidenti nonostante l'adozione delle migliori pratiche di sicurezza Kubernetes.
KSPM offre una visibilità continua sulla conformità e l'allineamento dei controlli Kubernetes ai quadri normativi è ormai essenziale per l'adozione da parte delle aziende. La gestione della sicurezza Kubernetes (KSPM) valuta continuamente le configurazioni dei cluster rispetto ai parametri di sicurezza di base, identificando in tempo reale configurazioni errate, violazioni delle politiche e lacune nella conformità.
Gli strumenti KSPM come Kubescape, Wiz, Prisma Cloud e Sysdig forniscono una valutazione continua delle configurazioni dei cluster Kubernetes rispetto alle linee guida di sicurezza, inclusi i benchmark CIS, gli standard di sicurezza Pod e le politiche organizzative personalizzate. Il benchmark CIS Kubernetes, valutato da kube-bench, rimane la linea guida più ampiamente adottata per il rafforzamento dei cluster. L'OWASP Kubernetes Top 10 fornisce un quadro di riferimento dei rischi in ordine di priorità che copre la configurazione non sicura del carico di lavoro (K01), le vulnerabilità della catena di fornitura (K02), l'RBAC eccessivamente permissivo (K03), le lacune nell'applicazione delle politiche (K04) e la registrazione inadeguata (K05) attraverso componenti vulnerabili (K10). Una versione aggiornata è attualmente in fase di elaborazione per il 2025.
La guida NSA/CISA Kubernetes Hardening Guide v1.2 (agosto 2022) rimane il riferimento autorevole del governo per la sicurezza di Kubernetes, coprendo i rischi della catena di approvvigionamento, gli attori malintenzionati e le minacce interne. L'automazione della conformità si sta intensificando nel 2026, con le organizzazioni ora tenute a dimostrare la conformità continua attraverso la raccolta automatizzata di prove piuttosto che valutazioni manuali periodiche (Veeam).
Tabella 3: Controlli di sicurezza Kubernetes mappati sui principali quadri normativi
I requisiti SBOM stanno evolvendo poiché l'OMB M-26-05 è passato a un approccio basato sul rischio nel gennaio 2026. I fornitori Cloud devono ora fornire SBOM degli ambienti di produzione runtime su richiesta, favorendo l'integrazione della generazione di SBOM nelle pipeline CI/CD di Kubernetes.
La sicurezza di Kubernetes sta maturando rapidamente grazie a strumenti basati su eBPF, al rafforzamento delle piattaforme e al passaggio da strategie di difesa basate esclusivamente sulla prevenzione a strategie basate sul rilevamento. Diversi sviluppi nel 2025-2026 stanno ridefinendo il modo in cui le organizzazioni affrontano l'architettura di sicurezza di Kubernetes.
Il rafforzamento della piattaforma sta accelerando. Nel corso del 2025, sei importanti funzionalità di sicurezza hanno raggiunto uno stato stabile in Kubernetes v1.32-v1.35, tra cui miglioramenti ai token Bound ServiceAccount, container sidecar, montaggi ricorsivi di sola lettura, autorizzazione basata su selettori, restrizioni alle richieste anonime e cancellazione ordinata degli spazi dei nomi. Altre otto funzionalità dovrebbero essere completate nel 2026, tra cui spazi dei nomi utente, certificati Pod per mTLS e autorizzazione al pull delle immagini (CNCF 2025).
Le transizioni delle infrastrutture critiche richiedono attenzione. Ingress-NGINX raggiungerà la fine del ciclo di vita nel marzo 2026, senza ulteriori rilasci, correzioni di bug o patch di sicurezza dopo tale data. Il Comitato di risposta alla sicurezza di Kubernetes raccomanda la migrazione all'API Gateway (blog Kubernetes). Le organizzazioni che mantengono controller Ingress-NGINX legacy sono esposte a vulnerabilità non corrette.
La validazione del mercato è ai massimi livelli storici. L'acquisizione di Wiz da parte di Google per 32 miliardi di dollari, la più grande acquisizione mai realizzata nel settore della sicurezza informatica, conferma la validità del mercato della sicurezza cloud e segnala che gli strumenti e le piattaforme di sicurezza Kubernetes sono una priorità strategica per i principali attori del settore (The Register).
L'adozione di DevSecOps sta accelerando. Il 42% delle organizzazioni riferisce ora di iniziative DevSecOps avanzate, mentre il 48% è nelle fasi iniziali (Red Hat 2024). Questo passaggio da pratiche di sicurezza aggiuntive a pratiche di sicurezza integrate sta riducendo il divario tra la velocità di sviluppo e la copertura di sicurezza.
L'approccio Vectra AI alla sicurezza di Kubernetes si concentra sul rilevamento comportamentale delle minacce e Attack Signal Intelligence. Anziché affidarsi esclusivamente alla scansione delle configurazioni e all'applicazione delle politiche, Vectra AI i modelli di traffico di rete cloud ibridi, compreso il traffico est-ovest all'interno dei cluster Kubernetes, per rilevare gli indicatori comportamentali degli attacchi attivi. Questo approccio si basa sulla filosofia del "presupposto di compromissione": gli aggressori intelligenti finiranno per aggirare i controlli di prevenzione, quindi rilevare il loro comportamento post-compromissione, inclusi i movimenti laterali, l'escalation dei privilegi e l'esfiltrazione dei dati, è ciò che riduce il rischio effettivo. Fornendo rilevamento e risposta di rete che integrano gli strumenti basati sulla configurazione, le organizzazioni ottengono la visibilità necessaria per identificare le minacce che la sola prevenzione non è in grado di fermare.
La sicurezza Kubernetes è l'insieme di pratiche, strumenti e politiche che proteggono i carichi di lavoro containerizzati e la loro infrastruttura di orchestrazione durante l'intero ciclo di vita dell'applicazione, dalla creazione dell'immagine alla distribuzione e al funzionamento in fase di esecuzione. Comprende il rafforzamento della configurazione, il controllo degli accessi tramite RBAC, la segmentazione della rete tramite politiche di rete, la gestione dei segreti, il rilevamento delle minacce in fase di esecuzione e il monitoraggio della conformità. A differenza della sicurezza dei container, che si concentra sulle singole immagini e sui runtime, la sicurezza di Kubernetes riguarda il livello di orchestrazione, inclusi il server API, l'archivio dati etcd, i controller di ammissione e le configurazioni a livello di cluster. Con il 90% delle organizzazioni che ha subito almeno un incidente nell'ultimo anno (Red Hat 2024), una sicurezza completa di Kubernetes è un imperativo aziendale, non un miglioramento opzionale.
No. Nella sua configurazione predefinita, Kubernetes privilegia la flessibilità e la velocità degli sviluppatori rispetto alla sicurezza. Di default, i cluster consentono una comunicazione illimitata tra pod, non crittografano i segreti inattivi in etcd, consentono l'accesso anonimo alle API in alcune configurazioni e non applicano gli standard di sicurezza dei pod. Le organizzazioni devono configurare attivamente RBAC con il minimo privilegio, implementare politiche di rete di rifiuto predefinite, abilitare la crittografia etcd, distribuire controller di ammissione e impostare la registrazione di audit prima che un cluster sia pronto per la produzione. L'urgenza è reale: i cluster AKS subiscono il loro primo tentativo di attacco entro 18 minuti dalla creazione, mentre i cluster EKS entro 28 minuti (Wiz 2025). Questo divario tra la configurazione predefinita e il funzionamento sicuro è il motivo per cui le best practice di sicurezza di Kubernetes sono fondamentali fin dal primo giorno.
Le 4 C sono Cloud, Cluster, Container e Code. Ogni livello si basa su quello sottostante. Cloud fornisce le basi attraverso politiche IAM, firewall di rete e crittografia in transito. I controlli a livello di cluster proteggono il livello di orchestrazione con RBAC, controller di ammissione, crittografia etcd e registrazione di audit. La sicurezza dei container rafforza i singoli carichi di lavoro attraverso la scansione delle immagini, il rafforzamento delle immagini di base, l'esecuzione rootless e i contesti di sicurezza. La sicurezza del codice affronta le vulnerabilità a livello di applicazione attraverso la scansione delle dipendenze, il rilevamento dei segreti e la verifica della catena di fornitura. Una debolezza in qualsiasi livello esterno compromette la sicurezza di tutti i livelli interni, rendendo le 4 C un framework pratico per identificare e colmare le lacune nell'intera architettura di sicurezza di Kubernetes.
Gli strumenti open source principali includono Falco (CNCF Graduated) per il rilevamento delle minacce in fase di esecuzione tramite il monitoraggio delle chiamate di sistema basato su eBPF, Trivy per la scansione completa delle vulnerabilità delle immagini dei container e delle configurazioni Kubernetes, Kubescape (CNCF Incubating) per la gestione della sicurezza in oltre 25.000 aziende, OPA/Gatekeeper e Kyverno per il controllo degli accessi e l'applicazione delle politiche, kube-bench per la valutazione della conformità al benchmark CIS Kubernetes e Tetragon/Cilium per l'osservabilità della sicurezza basata su eBPF con un overhead della CPU inferiore all'1%. Le piattaforme aziendali di fornitori come Wiz, Sysdig e Prisma Cloud supporto commerciale e set di funzionalità più ampi. Lo stack open source consigliato di Kubescape, Falco, Trivy e Cilium fornisce una copertura completa dalla compilazione al runtime con un overhead totale della CPU dell'1-2,5%.
La gestione della sicurezza di Kubernetes (KSPM) fornisce una valutazione continua delle configurazioni dei cluster rispetto a standard di sicurezza quali CIS Kubernetes Benchmarks, Pod Security Standards e politiche aziendali personalizzate. Gli strumenti KSPM identificano automaticamente e in tempo reale configurazioni errate, violazioni delle politiche e lacune di conformità nei cluster, sostituendo le valutazioni manuali periodiche. Tra i principali strumenti KSPM figurano Kubescape, Wiz, Prisma Cloud e Sysdig. A differenza della scansione puntuale, KSPM offre una visibilità continua sulla deriva della configurazione e sulla conformità alle politiche, sempre più richiesta dai quadri normativi tra cui HIPAA, PCI DSS, SOC 2 e NIST 800-53. Con l'intensificarsi dell'automazione della conformità nel 2026, KSPM è diventato un'infrastruttura essenziale per le implementazioni Kubernetes aziendali.
Kubernetes fornisce politiche di rete che controllano il flusso di traffico tra i pod ai livelli 3 e 4 (indirizzi IP e porte). Per impostazione predefinita, tutte le comunicazioni da pod a pod sono consentite senza restrizioni, creando una rete piatta che rende banale il movimento laterale per gli aggressori. Le organizzazioni devono implementare politiche di rete di tipo "default-deny" sia per il traffico in entrata che in uscita, consentendo esplicitamente solo i percorsi di comunicazione necessari. Per un controllo più granulare, Cilium fornisce l'applicazione di politiche di rete basate su eBPF al livello 7 (livello del protocollo applicativo), mentre soluzioni di service mesh come Istio o Linkerd aggiungono TLS reciproco (mTLS) per la comunicazione crittografata tra pod. Oltre all'applicazione delle politiche, NDR fornisce visibilità sui modelli di traffico est-ovest per rilevare comunicazioni anomale che le violazioni delle politiche da sole non sono in grado di individuare.
La OWASP Kubernetes Top 10 è un elenco prioritario dei rischi di sicurezza più critici negli ambienti Kubernetes, che fornisce un quadro condiviso per la valutazione dei rischi e la mappatura dei controlli. I rischi attuali includono configurazione non sicura del carico di lavoro (K01), vulnerabilità della catena di fornitura (K02), RBAC eccessivamente permissivo (K03), mancanza di applicazione centralizzata delle politiche (K04), registrazione e monitoraggio inadeguati (K05), autenticazione non funzionante (K06), mancanza di segmentazione della rete (K07), errori nella gestione dei segreti (K08), componenti del cluster configurati in modo errato (K09) e componenti Kubernetes obsoleti e vulnerabili (K10). Ogni rischio è associato a controlli specifici che le organizzazioni possono implementare. È attualmente in corso un aggiornamento per il 2025 attraverso un sondaggio della comunità. In combinazione con il CIS Kubernetes Benchmark e la NSA/CISA Kubernetes Hardening Guide, l'OWASP Top 10 fornisce un quadro completo dei rischi per la conformità della sicurezza di Kubernetes.