Kubernetes security: la superficie d’attacco è quasi sempre autoinflitta

La Kubernetes security ha un avversario prevalente, e non è l’attaccante più sofisticato: è la configurazione. La piattaforma che orchestra i container in produzione nella maggior parte delle grandi organizzazioni è potente e flessibile, ma molte delle sue impostazioni predefinite privilegiano il funzionamento sulla restrizione. La conseguenza è che la superficie d’attacco di un cluster, più che subita, viene costruita da chi lo gestisce, una scelta di default accettata alla volta.

Non è un’impressione soggettiva, anche se le sfumature cambiano edizione per edizione. Le indagini Red Hat sullo stato della sicurezza di Kubernetes registrano da tempo che la grande maggioranza delle organizzazioni dichiara di aver subito almeno un incidente legato a container o cluster. Nelle rilevazioni del 2021 e del 2022 la configurazione errata era la preoccupazione più citata, intorno al 59 per cento; nelle edizioni più recenti il quadro si è distribuito tra errori di configurazione, vulnerabilità introdotte in fase di build e incidenti a runtime, segno che il problema non si è risolto ma si è articolato. Sono dati autodichiarati, da leggere come fotografia di percezione e non come misura assoluta, ma la configurazione resta uno dei vettori dominanti. La sicurezza di un cluster si gioca prima nelle scelte di chi lo configura che nella corsa alle patch.

La superficie d’attacco è quasi sempre autoinflitta

Il caso limite lo ha mostrato il gruppo di vulnerabilità battezzato IngressNightmare, divulgato nel marzo 2025. La falla più grave dell’insieme, CVE-2025-1974, valutata 9,8 su 10 nella scala CVSS, colpiva l’ingress controller basato su NGINX: concatenata a una delle vulnerabilità di annotation injection dello stesso gruppo, permetteva l’esecuzione di codice da remoto senza autenticazione. Il punto interessante non è il difetto in sé, ma il raggio dell’esplosione: secondo l’analisi pubblicata dai ricercatori di Wiz sulla vulnerabilità, da quel singolo componente un attaccante poteva leggere i segreti conservati in tutti i namespace del cluster, fino a prenderne il controllo completo. La stessa ricerca stimava che una quota rilevante degli ambienti cloud fosse esposta, con migliaia di cluster che pubblicavano il controller di ammissione direttamente su Internet.

Quel raggio d’azione è il vero insegnamento. In un cluster ben segmentato, la compromissione di un componente resta circoscritta. In un cluster configurato secondo i default, un punto di ingresso diventa una chiave per tutto. La differenza non la fa l’esistenza del CVE, la fa la postura del cluster intorno ad esso. Ed è qui che la sicurezza smette di essere una reazione e diventa progettazione.

RBAC: il punto più sbagliato, quasi ovunque

Se esiste un singolo elemento in cui le configurazioni errate si concentrano, è il controllo degli accessi. Il modello di autorizzazione di Kubernetes, il role-based access control o RBAC, è potente ma facile da impostare male, e il margine tra un permesso ragionevole e un permesso pericoloso è sottile. L’errore archetipico ha una forma precisa: un binding che assegna il ruolo cluster-admin al service account predefinito di un namespace. Da quel momento ogni pod in quel namespace eredita il controllo totale del cluster, e un attaccante che comprometta una qualunque applicazione di quel namespace si trova in mano le chiavi dell’intera piattaforma.

La radice del problema è quasi sempre la stessa: permessi concessi in eccesso per comodità, e mai più ristretti. Un service account che potrebbe limitarsi a leggere una risorsa ottiene il diritto di crearne e cancellarne, perché così l’applicazione funziona subito e nessuno torna a stringere i privilegi dopo. Il principio del minimo privilegio, ovvio in teoria, è disatteso in pratica perché richiede di sapere esattamente cosa ciascun componente deve fare, e quella conoscenza costa tempo. La Kubernetes security su questo fronte non è una tecnologia da attivare, è una disciplina di igiene: assegnare il permesso necessario e niente di più, e verificare periodicamente che i token in circolazione non valgano più di quanto dovrebbero.

I segreti che non sono segreti

C’è un corollario del controllo degli accessi che molti scoprono troppo tardi: in Kubernetes i Secret, l’oggetto pensato per custodire credenziali e chiavi, sono conservati per impostazione predefinita come stringhe codificate in base64, non cifrate. La codifica non è cifratura, e la differenza non è accademica: chiunque ottenga accesso in lettura a quegli oggetti, tramite l’API o direttamente dal datastore etcd, li riporta in chiaro in un istante. È esattamente il motivo per cui una falla capace di leggere i Secret di tutti i namespace, come quella vista con IngressNightmare, ha un raggio d’azione tanto ampio. La contromisura è duplice e va attivata in modo esplicito, perché nessuna delle due è il default: abilitare la cifratura a riposo dei Secret in etcd, idealmente appoggiandosi a un servizio di gestione delle chiavi, e restringere via RBAC chi può leggerli, dato che il numero di identità autorizzate a eseguire get e list sui Secret è quasi sempre molto più alto del necessario. Dove la posta in gioco è alta, la scelta più solida è togliere del tutto le credenziali dal cluster e affidarle a un gestore di segreti esterno, integrato tramite operatore.

Kubernetes security parte dal pod: i Pod Security Standards

Il livello successivo è il contenimento di ciò che un pod può fare sul nodo che lo ospita. Qui la piattaforma ha cambiato approccio in modo significativo. Il vecchio meccanismo, il PodSecurityPolicy, è stato rimosso nella versione 1.25 di Kubernetes, sostituito dal Pod Security Admission e dai Pod Security Standards, che definiscono tre profili di sicurezza progressivi. Il profilo privileged non impone restrizioni. Il profilo baseline blocca le tecniche note di escalation dei privilegi restando compatibile con la maggior parte dei carichi. Il profilo restricted applica le pratiche di hardening più severe, dalla rinuncia ai privilegi di root all’isolamento dal filesystem del nodo.

La leva operativa sta nelle tre modalità con cui questi standard si applicano: enforce blocca i pod non conformi, audit registra le violazioni senza bloccare, warn avverte chi le produce. È un percorso, non un interruttore. La strada ragionevole parte da audit e warn per fotografare cosa girerebbe fuori standard, corregge le applicazioni che violano il profilo, e solo allora attiva enforce sul profilo restricted. Saltare la fase di osservazione e imporre subito il blocco è il modo più sicuro per rompere la produzione e indurre il team a disattivare tutto, riportando il cluster al punto di partenza.

Workload effimeri e la visibilità che manca

C’è un ostacolo strutturale che rende la Kubernetes security diversa dalla sicurezza dei sistemi tradizionali: i carichi di lavoro sono effimeri. Un pod nasce, vive pochi minuti o poche ore, muore e viene sostituito, e con lui spariscono le tracce. I controlli pensati per host stabili, che presuppongono di poter ispezionare una macchina che resterà lì domani, perdono aderenza. Servono visibilità e rilevamento a runtime capaci di seguire oggetti che cambiano in continuazione, e un inventario che sappia cosa sta girando adesso, non cosa è stato distribuito la settimana scorsa. Senza questa capacità, un comportamento anomalo dentro un container può comparire e svanire senza lasciare nulla da analizzare.

Admission control e rete: l’ultima barriera, e a volte la prima falla

Il controllo di ammissione è il guardiano che valuta ogni richiesta di creazione di una risorsa prima che venga accettata, e applica le politiche definite. È lo strato che traduce le regole in vincoli effettivi, e ben usato è una delle difese più efficaci del cluster. La lezione di IngressNightmare, però, è che lo stesso meccanismo, se esposto e vulnerabile, può diventare il punto di ingresso anziché la barriera. Un controllo di ammissione raggiungibile dalla rete dei pod, o peggio da Internet, è un bersaglio, non una protezione.

Usato bene, però, è lo strato dove la sicurezza diventa programmabile. I motori di policy come OPA Gatekeeper e Kyverno permettono di esprimere le regole come codice e applicarle al momento dell’ammissione: vietare i container privilegiati, imporre i profili di sicurezza, bloccare le immagini che provengono da registri non affidabili. È anche il punto in cui si può pretendere la provenienza del software, verificando che un’immagine sia firmata da chi dovrebbe averla prodotta, così da impedire l’esecuzione di artefatti manomessi lungo la catena di distribuzione. Tradurre le buone intenzioni di sicurezza in vincoli applicati in automatico, e non in raccomandazioni che qualcuno potrà sempre ignorare, è ciò che distingue un cluster governato da uno semplicemente configurato.

A chiudere il quadro c’è la rete interna. Per impostazione predefinita, in un cluster ogni pod può parlare con ogni altro pod: una topologia comoda per gli sviluppatori e ideale per un attaccante che, ottenuto un punto d’appoggio, vuole muoversi lateralmente. Le network policy servono a imporre una segmentazione di rete che limiti le comunicazioni a quelle effettivamente necessarie, idealmente partendo da un approccio default-deny in cui ciò che non è esplicitamente permesso è negato. È la stessa logica della microsegmentazione applicata all’interno del cluster, ed è ciò che trasforma un singolo container compromesso in un incidente contenuto invece che in una testa di ponte.

Hardening non è un progetto, è una postura

Conviene diffidare dell’idea che mettere in sicurezza un cluster sia un progetto con una data di fine. La guida all’hardening di Kubernetes pubblicata da NSA e CISA, nella sua versione 1.2 dell’agosto 2022, e i benchmark CIS dedicati alla piattaforma offrono una base solida di configurazioni di riferimento, ma sono fotografie di uno stato desiderato, non garanzie permanenti. Un cluster cambia di continuo: nuovi carichi, nuovi permessi, nuove dipendenze, e ogni modifica può reintrodurre una debolezza che si credeva risolta. La sicurezza, qui, è una proprietà da mantenere, non un traguardo da raggiungere.

Il rischio è concreto e attuale. Le campagne che colpiscono ambienti cloud-native sfruttano proprio questa deriva, e un worm cloud-native che si propaga tra infrastrutture mal configurate trova terreno fertile ovunque la postura sia stata impostata una volta e poi dimenticata. Il posture management continuo, cioè la verifica costante che la configurazione reale corrisponda a quella sicura, non è un lusso da grandi organizzazioni: è la sola risposta proporzionata a una piattaforma che si modifica ogni giorno.

La Kubernetes security, in fondo, non chiede di inseguire l’ultimo CVE, anche se le patch vanno applicate. Chiede di ribaltare il valore predefinito: progettare il cluster perché un componente compromesso resti un problema locale, e non la perdita dell’intera infrastruttura. La superficie d’attacco è quasi sempre autoinflitta, e questa è la cattiva notizia per chi gestisce un cluster oggi. È anche la buona notizia, perché ciò che ci si è costruiti da soli si può, con metodo, smontare.