Sicurezza Kubernetes e container: cosa controllare

La sicurezza di Kubernetes si gioca su sei piani: le immagini dei container, la configurazione dei pod, gli accessi (RBAC), la rete, i Secret, i log e gli aggiornamenti. Quasi tutti i problemi reali nascono da impostazioni lasciate ai valori di default, che in Kubernetes sono pensati per far funzionare le cose, non per chiuderle. Anche su un cluster gestito come EKS, AKS o GKE, una parte importante del lavoro resta a te.

Qui trovi cosa controllare su ciascun piano, in che ordine, quali default cambiare per primi e come misurare il risultato con il CIS Kubernetes Benchmark.

Perché Kubernetes è un problema di sicurezza a sé

Un cluster Kubernetes non è un server in più. È un sistema che crea, sposta e distrugge container da solo, governato da un'API: chi controlla l'API controlla tutto ciò che ci gira sopra. E le risorse cambiano ogni giorno, a ogni rilascio.

La Kubernetes Hardening Guide di NSA e CISA (versione 1.2, agosto 2022) indica tre fonti di compromissione comuni:

• Supply chain: un'immagine, una libreria o un componente dell'infrastruttura compromesso prima di arrivare nel cluster.
• Attori malevoli che sfruttano vulnerabilità e configurazioni errate del control plane, dei nodi o delle applicazioni nei container.
• Minacce interne: amministratori, utenti o fornitori cloud con accessi privilegiati che possono abusarne.

Sulla motivazione la guida è diretta: oltre al furto di dati, Kubernetes attira chi cerca capacità di calcolo, spesso per il mining di criptovalute. Quanto in fretta accada su risorse configurate male lo raccontiamo in errori di configurazione del cloud.

Cluster gestito: cosa fa il provider e cosa resta a te

Con un servizio gestito il provider si prende la parte più pesante, ma non tutta. Il modello di responsabilità condivisa di GKE, pubblicato da Google, lo scrive in modo chiaro.

Google gestisce l'infrastruttura fisica, il sistema operativo dei nodi, i componenti dei nodi (con un kubelet configurato secondo i CIS benchmark) e il control plane, compresi etcd e la configurazione dell'audit logging.

Al cliente restano:

• i workload: codice, file di build, immagini dei container, dati;
• le policy RBAC e IAM, e i container e i pod in esecuzione;
• la rotazione delle credenziali del cluster;
• l'aggiornamento dei node pool, automatico o manuale quando l'automatico è rinviato;
• il monitoraggio di cluster e applicazioni, e la risposta ad allarmi e incidenti.

Il riparto cambia nei dettagli fra EKS, AKS e GKE, e fra modalità standard e autopilot, ma la linea di fondo è la stessa: il provider tiene in piedi la piattaforma, cosa ci metti sopra e chi può toccarlo è affare tuo.

I sei piani da controllare

1. Immagini dei container

È il punto in cui entra la supply chain. Le regole di base:

• Scansiona le immagini per vulnerabilità note e configurazioni errate prima del rilascio e mentre girano: un'immagine pulita oggi può avere una CVE domani.
• Usa immagini minime e da registri di cui ti fidi. Meno pacchetti, meno superficie.
• Costruisci l'applicazione per girare come utente non root. La guida NSA e CISA osserva che per default molti servizi di container girano come root, e che le applicazioni girano da root anche quando non serve.
• Niente segreti dentro l'immagine: chiavi e token cotti in un layer restano leggibili da chiunque scarichi l'immagine.

2. Configurazione dei pod

Kubernetes definisce tre profili di sicurezza per i pod, i Pod Security Standards:

• Privileged: nessuna restrizione, ammette escalation di privilegio note. Pensato per i workload di sistema gestiti da utenti fidati.
• Baseline: blocca le escalation di privilegio note e ammette la configurazione minima di default di un pod.
• Restricted: il profilo più stretto, allineato alle pratiche correnti di hardening.

Li applica il controller Pod Security Admission, integrato in Kubernetes e stabile dalla versione 1.25, a livello di namespace. Ha tre modalità: enforce rifiuta il pod che viola il profilo, audit lo registra nel log di audit, warn mostra un avviso. Un percorso prudente è partire con audit e warn sul profilo Restricted, guardare cosa si romperebbe, poi passare a enforce namespace per namespace.

Fra i controlli che la guida NSA e CISA chiede di imporre: niente container privilegiati, niente accesso a hostPID, hostIPC, hostNetwork e ai percorsi del nodo, niente esecuzione come root, file system del container in sola lettura dove possibile.

3. Accessi e RBAC

L'API di Kubernetes è la porta principale, quindi i permessi contano più di qualsiasi altra cosa. Dalle buone pratiche RBAC della documentazione di Kubernetes:

• assegna i permessi a livello di namespace, con RoleBinding invece di ClusterRoleBinding dove possibile;
• evita i permessi con wildcard: valgono anche per i tipi di risorsa che verranno creati in futuro;
• usa l'account cluster-admin solo dove serve davvero;
• non aggiungere utenti al gruppo system:masters, che scavalca ogni controllo RBAC.

La guida NSA e CISA aggiunge un default da conoscere: sull'API server le richieste anonime sono abilitate per default, e la raccomandazione è disabilitarle. Sui servizi gestiti va verificato cosa ha impostato il provider.

4. Rete

Qui il default sorprende chi arriva da reti tradizionali. Secondo la documentazione di Kubernetes, un pod per default è non isolato, in ingresso e in uscita: accetta connessioni da qualsiasi altro pod e può aprirne verso qualsiasi destinazione. Un pod diventa isolato, in una direzione, solo quando una NetworkPolicy lo seleziona per quella direzione.

Due conseguenze pratiche:

• Parti da una policy di negazione esplicita per namespace e apri solo i flussi che servono, come raccomanda la guida NSA e CISA. Un container compromesso, altrimenti, vede tutto il cluster.
• Controlla il network plugin: le NetworkPolicy le applica il plugin di rete, e se il plugin non le supporta, crearle non ha alcun effetto.

5. Secret Kubernetes

Per default un Secret Kubernetes non è cifrato: è codificato in base64, che si decodifica con un comando. La documentazione di Kubernetes avverte che per default i Secret sono salvati non cifrati in etcd, l'archivio dell'API server, e che chiunque abbia accesso all'API o a etcd può leggerli o modificarli. C'è un dettaglio meno noto: chi può creare un pod in un namespace può leggere tutti i Secret di quel namespace, anche indirettamente, per esempio creando un Deployment.

I passi minimi indicati dalla documentazione sono quattro:

1. attivare la cifratura a riposo dei Secret;
2. scrivere regole RBAC con il minimo privilegio sull'accesso ai Secret;
3. limitare l'accesso ai soli container che ne hanno bisogno;
4. valutare un archivio di segreti esterno.

Sui servizi gestiti la cifratura a riposo può già essere attiva o attivabile con il servizio di gestione delle chiavi del provider: va verificato, non dato per scontato.

6. Log e aggiornamenti

Senza log di audit non sai chi ha fatto cosa sull'API. La guida NSA e CISA ricorda che su Kubernetes l'audit logging è disabilitato per default, e chiede di attivarlo, conservare i log fuori dal cluster e collegarli a un sistema di allarme. Sui cluster gestiti la configurazione dell'audit la tiene il provider, ma abilitare logging e monitoraggio e leggerli resta compito tuo.

Sugli aggiornamenti il calendario è stretto. Il progetto Kubernetes mantiene i rami delle tre minor release più recenti (a ottobre 2026: 1.37, 1.36 e 1.35) e ogni versione, dalla 1.19, riceve circa un anno di patch. Un cluster che resta indietro di qualche versione esce dal supporto in fretta.

Come misurare un cluster: il CIS Kubernetes Benchmark

Per sapere a che punto sei serve un metro comune. Il CIS Kubernetes Benchmark del Center for Internet Security raccoglie raccomandazioni di configurazione verificabili, ognuna con il controllo da fare e la correzione. Oltre alla versione per Kubernetes standard, il CIS pubblica versioni per i servizi gestiti, fra cui Amazon EKS, Azure AKS, Google GKE e GKE Autopilot, Oracle OKE e Red Hat OpenShift: conviene usare quella del servizio che hai, perché una parte dei controlli sul control plane non è in mano tua.

Come funzionano i benchmark CIS, i livelli e il modo di usarli come evidenza per un audit lo spieghiamo in CIS Benchmark: cos'è e come si usa.

Da dove partire

Se hai cluster in produzione e nessuno li ha mai guardati con occhio di sicurezza, questo è un ordine ragionevole:

1. Inventario: quanti cluster, su quali account e cloud, con quale versione, chi ha i permessi di amministrazione.
2. Esposizione: API server raggiungibile da internet, servizi esposti, accesso anonimo.
3. RBAC: chi ha cluster-admin, quali binding usano wildcard, quali service account hanno più permessi del necessario.
4. Secret: cifratura a riposo attiva, chi può leggerli, segreti finiti nelle immagini o nei manifest.
5. Pod: Pod Security Admission in audit su Restricted, poi enforce dove regge.
6. Rete: policy di negazione di default, namespace per namespace.
7. Log e aggiornamenti: audit attivo e letto da qualcuno, versioni dentro il supporto.

Il primo passo è sempre l'inventario: non si può mettere in ordine quello che non si vede.

Strumenti: dove entra una CNAPP

Fare questi controlli a mano su un cluster si può. Su più cluster, più account e rilasci settimanali diventa difficile, e soprattutto si perde il collegamento fra i problemi: un'immagine vulnerabile pesa diversamente se il pod è esposto e il suo service account legge i Secret dell'intero namespace.

È il lavoro di una CNAPP, che mette insieme postura delle configurazioni, vulnerabilità dei workload, permessi e Kubernetes in un solo modello. Wiz, di cui siamo partner, include la sicurezza di container e Kubernetes fra i moduli della piattaforma, dalla fase di build all'esecuzione; il rilevamento a runtime passa dal Wiz Sensor, che Wiz indica come componente aggiuntivo. Come funziona la piattaforma lo trovi in Wiz cos'è: la cloud security che ora è di Google.

Uno strumento trova i problemi. Qualcuno deve poi decidere cosa correggere prima, aprire le modifiche e verificare che restino chiuse: è lì che si vede se la sicurezza del cluster è un processo o un report.

In sintesi: la sicurezza di Kubernetes e dei container sta in sei piani (immagini, pod, RBAC, rete, Secret, log e aggiornamenti) e parte dal cambiare i default: pod che parlano con tutti, Secret non cifrati, container che girano come root. Su un cluster gestito il provider tiene la piattaforma, ma workload, permessi, dati e risposta agli incidenti restano a te. Il CIS Kubernetes Benchmark è il metro per misurare a che punto sei.

Se vuoi sapere com'è messo il tuo ambiente cloud, cluster Kubernetes compresi, partiamo da una fotografia della sicurezza del tuo cloud.