Proteggi i tuoi cluster Kubernetes con il Cloud Penetration Testing

Kubernetes è diventato lo standard di riferimento per l'orchestrazione dei container. È potente, si adatta magnificamente e consente agli sviluppatori di rilasciare codice più velocemente che mai. Ma siamo onesti: Kubernetes è anche incredibilmente complesso. Tra l'API server, etcd, kubelet, i pod e una montagna di file YAML, ci sono molti punti in cui le cose possono andare male. Una singola impostazione di controllo degli accessi basato sui ruoli (Role-Based Access Control - RBAC) configurata in modo errato o un account di servizio con privilegi eccessivi può trasformare un bug minore in un'acquisizione completa del cluster.

La maggior parte dei team inizia con una configurazione "predefinita", pensando che il servizio gestito del provider cloud abbia tutto bloccato. Sebbene GKE, EKS e AKS forniscano una base di partenza decente, non correggono magicamente le vulnerabilità a livello di applicazione o gli errori di configurazione personalizzati. La realtà è che la "superficie di attacco" di un cluster Kubernetes è enorme. Non stai solo proteggendo un server; stai proteggendo un sistema distribuito di microservizi interconnessi.

È qui che entra in gioco il cloud pentesting. Le scansioni di sicurezza tradizionali spesso non rilevano i modi sfumati in cui un aggressore può muoversi lateralmente all'interno di un cluster. Hai bisogno di un approccio proattivo che simuli il modo in cui pensa un vero aggressore, partendo da un pod compromesso e cercando di raggiungere il nodo o l'API dei metadati del provider cloud. Nel momento in cui uno scanner di vulnerabilità segnala una CVE, un aggressore esperto potrebbe aver già utilizzato un'autorizzazione configurata in modo errato per aumentare i propri privilegi.

In questa guida, approfondiremo le specifiche della protezione di Kubernetes. Esamineremo i vettori di attacco più comuni, come proteggere i tuoi cluster e perché sfruttare una piattaforma basata su cloud come Penetrify può aiutarti a trovare queste falle prima che lo faccia qualcun altro.

Comprendere la superficie di attacco di Kubernetes

Per proteggere un cluster, devi prima capire come può essere violato. Kubernetes non è un monolite; è una raccolta di componenti che comunicano tra loro. Se uno qualsiasi di questi canali di comunicazione è aperto o fiducioso, hai un problema.

Il piano di controllo: il cervello dell'operazione

Il piano di controllo è l'obiettivo principale per qualsiasi aggressore. Se ottengono l'accesso all'API server, è finita. Possono distribuire pod dannosi, rubare segreti o eliminare l'intera infrastruttura. I problemi più comuni qui sono:

• Accesso API non autenticato: accade più spesso di quanto si pensi. Qualcuno lascia l'API server aperto alla rete internet pubblica per il "debug" e si dimentica di chiuderlo.
• Policy RBAC deboli: concedere privilegi cluster-admin a uno sviluppatore che ha solo bisogno di visualizzare i log è una ricetta per il disastro.
• etcd esposto: etcd è il database in cui è archiviato tutto lo stato del cluster. Se un aggressore colpisce etcd direttamente, può bypassare completamente l'API server e riscrivere la realtà del cluster.

Il piano dati: dove avviene il lavoro

Qui è dove vivono i tuoi pod e nodi. Mentre il piano di controllo è il cervello, il piano dati è il corpo. Gli aggressori spesso cercano di ottenere un punto d'appoggio qui per primi.

• Container Escape: se un container è in esecuzione come root o ha accesso privilegiato, un aggressore può "uscire" dal container e ottenere l'accesso al nodo host sottostante.
• Comunicazione Pod-to-Pod: per impostazione predefinita, Kubernetes non blocca il traffico tra i pod. Se un aggressore compromette un piccolo pod rivolto al web, può annusare il traffico o attaccare ogni altro pod nel cluster.
• Gestione non sicura dei segreti: archiviare password o chiavi API in testo semplice all'interno di un ConfigMap o anche utilizzare i K8s Secrets di base (che sono solo codificati in base64) è un errore comune.

L'elemento umano e CI/CD

Spesso dimentichiamo che il cluster è gestito da persone e pipeline.

• File Kubeconfig trapelati: uno sviluppatore invia accidentalmente il suo .kube/config a un repository GitHub pubblico e improvvisamente il mondo ha accesso amministrativo al tuo cluster di produzione.
• Immagini avvelenate: utilizzo di un'immagine non verificata da Docker Hub che contiene una backdoor.
• Vulnerabilità della pipeline: aggressori che prendono di mira il runner Jenkins o GitLab che ha le autorizzazioni per eseguire il deployment nel cluster.

Vulnerabilità comuni di Kubernetes e come sfruttarle (e fermarle)

Una cosa è leggere un elenco di rischi; un'altra è capire come si svolgono effettivamente. Esaminiamo alcuni scenari del mondo reale.

Scenario 1: l'account di servizio con privilegi eccessivi

Immagina un pod che esegue un semplice agente di monitoraggio. Per qualche motivo, lo sviluppatore gli ha assegnato un ServiceAccount con un ClusterRole che gli consente di list e get segreti nell'intero namespace.

L'attacco:

1. Un aggressore trova un bug di esecuzione di codice remoto (Remote Code Execution - RCE) nell'agente di monitoraggio.
2. Trovano il token dell'account di servizio montato in /var/run/secrets/kubernetes.io/serviceaccount/token.
3. Utilizzando kubectl, utilizzano questo token per interrogare l'API server: kubectl get secrets.
4. Trovano la password del database e le chiavi di accesso del provider cloud.

La correzione: Implementare il Principio del privilegio minimo. Utilizzare Roles specifici invece di ClusterRoles quando possibile. Utilizzare strumenti come audit2rbac per analizzare quali autorizzazioni vengono effettivamente utilizzate ed eliminare il resto.

Scenario 2: il Container Escape privilegiato

Un team distribuisce uno strumento di registrazione che richiede la modalità "privilegiata" per visualizzare le interfacce di rete dell'host.

L'attacco:

1. L'attaccante compromette il pod di logging.
2. Poiché il pod è privilegiato, può vedere i dispositivi dell'host.
3. Monta il filesystem root dell'host (/) nel container.
4. Crea un job cron sull'host o aggiunge una nuova chiave SSH al file authorized_keys dell'host.
5. Ora ha pieno accesso root al Node. Da lì, può potenzialmente accedere ad altri pod sullo stesso nodo.

La Soluzione: Evitare privileged: true a tutti i costi. Se hai bisogno di funzionalità specifiche (come NET_ADMIN), concedi solo quelle specifiche funzionalità usando il blocco capabilities nel contesto di sicurezza. Usa un controller Pod Security Admission (PSA) per applicare policy "Baseline" o "Restricted".

Scenario 3: La Fuga di Metadata API

Negli ambienti cloud (AWS, GCP, Azure), i pod possono spesso raggiungere il servizio di metadati cloud (es., 169.254.169.254).

L'Attacco:

1. Un attaccante ottiene accesso a un pod.
2. Esegue un curl sull'endpoint dei metadati: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/.
3. Il servizio di metadati restituisce credenziali AWS temporanee per il ruolo IAM collegato al worker node.
4. L'attaccante usa queste credenziali per accedere ai bucket S3 o modificare le impostazioni VPC.

La Soluzione: Usa le Network Policies per bloccare tutto il traffico di uscita verso l'indirizzo IP dei metadati. In alternativa, usa l'accesso basato sull'identità come AWS IRSA (IAM Roles for Service Accounts) o Azure Pod Identity in modo che i pod ottengano le proprie identità limitate invece di ereditare l'identità del nodo.

Perché la Scansione Tradizionale Non È Sufficiente

Probabilmente hai usato uno scanner di vulnerabilità. Ti dice che la tua immagine Alpine Linux ha tre CVE di media gravità. È utile, ma non è "sicurezza".

La scansione è passiva. Il Penetration Testing è attivo.

Uno scanner può dirti che una libreria è obsoleta. Non può dirti che la tua configurazione RBAC consente a uno sviluppatore di eliminare accidentalmente il database di produzione. Non può dirti che un attaccante può usare una specifica catena di errori di configurazione per saltare da un pod frontend all'amministratore del cluster.

Il cloud pentesting coinvolge la "catena di exploit". Un attaccante non trova solo un bug; trova una sequenza di piccoli errori che, quando combinati, portano a una compromissione totale.

Per esempio:

• Passo 1: Trova un'immagine obsoleta (lo scanner lo trova).
• Passo 2: Usa quell'immagine per ottenere una shell (lo scanner non può farlo).
• Passo 3: Trova un token trapelato nel filesystem (lo scanner potrebbe non rilevarlo).
• Passo 4: Usa il token per passare a un pod più privilegiato (lo scanner sicuramente non può farlo).

Questo è il motivo per cui le aziende si stanno muovendo verso valutazioni di sicurezza continue. Invece di un audit annuale, usano piattaforme cloud-native per simulare costantemente questi attacchi. Penetrify semplifica questo fornendo un ambiente gestito in cui queste simulazioni possono avvenire senza la necessità di costruire il tuo "attack lab".

Una Guida Passo-Passo per Rafforzare il Tuo Cluster Kubernetes

Se stai fissando un cluster complesso e non sai da dove cominciare, segui questa checklist. Andremo dalle "vittorie facili" ai cambiamenti architetturali più complessi.

Fase 1: La Frutta a Portata di Mano (Vittorie Facili)

1. Disabilita l'Automounting del Token dell'Account di Servizio Predefinito: Di default, K8s monta un token in ogni pod. La maggior parte dei pod non ha bisogno di comunicare con l'API server. Imposta automountServiceAccountToken: false nel tuo PodSpec.
2. Aggiorna le Tue Immagini: Usa uno strumento come Trivy o Grype per scansionare le tue immagini durante la pipeline CI/CD. Se un'immagine ha una vulnerabilità di alta gravità, fai fallire la build.
3. Rimuovi le Autorizzazioni Non Necessarie: Controlla i tuoi ClusterRoles. Se vedi * nei campi resources o verbs, è un campanello d'allarme.
4. Proteggi l'API Server: Assicurati che l'API server non sia accessibile dalla rete internet aperta. Usa un load balancer con whitelisting IP o un endpoint privato.

Fase 2: Implementazione dei Controlli di Rete

1. Network Policy di Default Deny: Di default, tutti i pod possono comunicare con tutti i pod. Cambia questa impostazione. Crea una policy "Default Deny" per tutto il traffico in entrata e in uscita, quindi consenti esplicitamente solo le connessioni necessarie per il funzionamento dell'app.
2. Isolamento dei Namespace: Usa i namespace per separare gli ambienti (dev, staging, prod) e i diversi team. Anche se i namespace non sono un confine di sicurezza rigido, rendono molto più facile applicare Network Policies e RBAC.
3. Filtraggio Egress: Non permettere ai tuoi pod di comunicare con l'intera internet. Se il tuo pod ha bisogno solo di comunicare con una specifica API di gateway di pagamento, limita l'uscita a quello specifico intervallo IP o nome DNS.

Fase 3: Sicurezza Runtime e Applicazione delle Policy

1. Implementa Pod Security Admissions (PSA): Usa il PSA integrato per assicurarti che nessun pod sia in esecuzione come root o utilizzi la rete host.
2. Usa uno Strumento di Sicurezza Runtime: Strumenti come Falco possono avvisarti in tempo reale se viene aperta una shell all'interno di un pod o se viene letto un file sensibile (come /etc/shadow).
3. Filesystem Root di Sola Lettura: Ove possibile, imposta readOnlyRootFilesystem: true. Questo impedisce agli attaccanti di scaricare toolset (come nmap o netcat) nel container se ottengono una shell.

Fase 4: Gestione dell'Identità e dei Segreti

1. Smetti di usare i segreti K8s per dati sensibili: I segreti K8s sono codificati solo in base64. Utilizza un gestore di segreti dedicato come HashiCorp Vault, AWS Secrets Manager o Azure Key Vault.
2. Token di breve durata: Abbandona i token di lunga durata. Utilizza OIDC (OpenID Connect) per l'autenticazione utente al cluster.
3. Audit Logging: Abilita i log di audit di Kubernetes. Se si verifica una violazione, devi sapere esattamente chi ha chiamato quale API e quando. Senza log, stai solo tirando a indovinare.

Confronto tra diversi approcci di sicurezza

È facile confondersi con la giungla di acronimi degli strumenti di sicurezza. Ecco un'analisi comparativa dei diversi metodi e di come si inseriscono nella tua strategia.

Approccio	Cosa fa	Pro	Contro	Quando usarlo
Vulnerability Scanning	Verifica la presenza di CVE note in immagini/pacchetti.	Veloce, automatizzato, individua bug "noti".	Non rileva errori di configurazione e falle logiche.	Ogni singola build in CI/CD.
Configuration Auditing	Verifica i file YAML rispetto ai benchmark (come CIS).	Trova errori comuni (ad esempio, pod privilegiati).	Può produrre molti "False Positives" o rumore.	Pre-deployment e periodicamente.
Runtime Protection	Monitora i pod attivi per comportamenti anomali.	Individua Zero Day e attacchi attivi.	Può essere complesso da ottimizzare; elevato volume di avvisi.	Ambienti di produzione.
Cloud Pentesting	Simula il percorso di un attaccante umano.	Trova kill chain complesse e falle logiche.	Richiede più tempo di una scansione.	Trimestralmente o dopo modifiche importanti.

Il segreto è che nessuno di questi è "sufficiente" da solo. Hai bisogno di un approccio a strati. Scansiona le immagini per fermare i bug noti, controlla le configurazioni per fermare gli errori comuni, monitora il runtime per individuare le minacce attive e fai un Penetration Test per trovare le lacune che gli altri tre hanno perso.

Scalare la tua sicurezza con piattaforme Cloud-Native

Per un'azienda di medie dimensioni, assumere un esperto di sicurezza Kubernetes a tempo pieno è costoso. La maggior parte dei team IT è già sovraccarica. È qui che il modello di "Cloud Pentesting" risolve un vero problema aziendale.

Invece di cercare di costruire un "red team" interno, puoi utilizzare una piattaforma come Penetrify per colmare il divario. Ecco perché è importante per K8s in particolare:

1. Nessun overhead hardware L'impostazione di un ambiente sicuro per condurre Penetration Test su un cluster spesso richiede un mirror del tuo ambiente di produzione. Questo comporta molte spese cloud. Una piattaforma cloud-native ti consente di eseguire queste valutazioni attraverso un'architettura gestita, riducendo la necessità di creare costosi "cluster di test" che rimangono inutilizzati.

2. Scalabilità on-demand Le tue esigenze di sicurezza cambiano. Forse stai lanciando un nuovo microservizio per un grande cliente, oppure stai migrando da una configurazione VM legacy a EKS. Non hai bisogno di un pentester ogni singolo giorno, ma ne hai bisogno durante queste finestre ad alto rischio. Le piattaforme cloud ti consentono di aumentare o diminuire la frequenza dei test in base al tuo ciclo di rilascio.

3. Integrazione con i flussi di lavoro Il problema più grande con il Penetration Testing tradizionale è il "Report PDF". Ricevi un documento di 50 pagine, rimane in un'e-mail per tre settimane e poi uno sviluppatore deve creare manualmente ticket Jira per ogni scoperta. Le piattaforme moderne inviano i risultati direttamente ai tuoi sistemi SIEM o di ticketing esistenti. Quando viene trovata una vulnerabilità in un cluster K8s, dovrebbe diventare immediatamente un ticket nel backlog, non un punto elenco in un documento.

Scenario reale: l'attacco del "percorso di minor resistenza"

Per illustrare perché ci concentriamo sulle "catene" di vulnerabilità, tracciamo un ipotetico attacco a un sito di e-commerce basato su Kubernetes.

La configurazione:

• Un'app React frontend in esecuzione in un pod.
• Un pod API backend.
• Un pod database.
• Un'istanza Prometheus per il monitoraggio.

La catena di attacco:

1. L'ingresso: L'attaccante trova una vulnerabilità Server-Side Request Forgery (SSRF) nell'app frontend. Questo è un bug web comune.
2. La ricognizione: Utilizzando l'SSRF, l'attaccante non può raggiungere il database, ma può raggiungere il DNS interno di Kubernetes. Scopre che il servizio Prometheus è in esecuzione sulla porta 9090.
3. Il pivot: Scopre che l'istanza Prometheus ha una dashboard aperta senza password. Nella dashboard, trova un'etichetta che rivela gli indirizzi IP interni di tutti gli altri pod nel namespace.
4. L'escalation: Utilizza di nuovo l'SSRF, ma questa volta prende di mira il server API interno utilizzando un token trapelato che ha trovato in un log di Prometheus (che stava accidentalmente registrando le intestazioni).
5. I gioielli della corona: Il token ha il permesso get secrets. Estrae la password di root del database e scarica l'intera tabella dei clienti.

Come fermare questa catena? Nota che la maggior parte di questi non sono bug "critici" di per sé. Un SSRF è male, ma se hai Network Policies che bloccano l'accesso al pod Prometheus, l'attacco si ferma al passaggio 2. Se Prometheus è autenticato, si ferma al passaggio 3. Se il token dell'account di servizio non è automounted, si ferma al passaggio 4.

Questo è ciò che trova il cloud pentesting. Non si limita a dire "Hai un SSRF"; dice "Il tuo SSRF consente a un attaccante di rubare il tuo database tramite Prometheus". Questo è il tipo di intuizione che guida effettivamente la priorità della sicurezza.

Errori comuni che i team commettono quando proteggono K8s

Anche con le migliori intenzioni, le persone sbagliano. Ecco le insidie più comuni.

1. Fidarsi del "Cloud Default"

Molti team presumono che, poiché utilizzano GKE o EKS, il "cluster" sia sicuro. Ricorda: il provider cloud protegge l'infrastruttura (l'hardware, l'hypervisor, la disponibilità del control plane), ma tu proteggi la configurazione. Se distribuisci un pod come root, AWS non ti fermerà.

2. Eccessiva fiducia nei "Security Groups"

I security groups (firewall) sono ottimi per bloccare il traffico esterno, ma sono inutili per il traffico interno pod-to-pod. Una volta che un pacchetto è all'interno del cluster, il security group non lo vede. Devi utilizzare le Kubernetes Network Policies per la segmentazione interna.

3. Ignorare la fase di "Build"

Aspettare che l'app sia distribuita per scansionarla. Questo è un incubo per gli sviluppatori. Quando gli dici "questa immagine è vulnerabile", sono già passati alla funzionalità successiva. Sposta la sicurezza a sinistra. Inserisci la scansione nella pipeline CI/CD in modo che lo sviluppatore riceva l'errore mentre sta ancora scrivendo il codice.

4. Non testare il lato "Umano"

Puoi avere il cluster più sicuro del mondo, ma se il tuo lead dev memorizza il cluster-admin kubeconfig in un canale Slack pubblico, non importa nulla. La sicurezza è una cultura, non solo un insieme di file YAML.

FAQ: Sicurezza di Kubernetes e Cloud Pentesting

D: La scansione automatizzata è la stessa cosa del pentesting?

R: No. La scansione automatizzata è come un rilevatore di fumo: ti dice che c'è un problema in base a schemi noti. Il Penetration Testing è come un pompiere: un essere umano (o una simulazione avanzata) che guarda la struttura dell'edificio, controlla le uscite e trova il punto in cui una scintilla potrebbe innescare un incendio. Hai bisogno di entrambi.

D: Quanto spesso dovrei sottoporre a Penetration Test i miei cluster Kubernetes?

R: Come minimo, una volta all'anno. Tuttavia, per le aziende con cicli di rilascio rapidi, sono preferibili test trimestrali o test "basati su eventi" (dopo un'importante modifica dell'architettura o il lancio di una nuova funzionalità). La valutazione continua è il gold standard.

D: Il Penetration Testing può mandare in crash il mio cluster di produzione?

R: Può succedere, se fatto male. Questo è il motivo per cui il cloud pentesting professionale viene solitamente eseguito in un ambiente di staging che rispecchia la produzione. Un buon pentester sa come testare attentamente senza far cadere i tuoi pod.

D: Qual è più importante: RBAC o Network Policies?

R: Nessuno dei due è "più" importante; risolvono problemi diversi. RBAC controlla chi può fare cosa (Autorizzazione). Network Policies controlla chi può parlare con chi (Comunicazione). Se hai un ottimo RBAC ma nessuna Network Policies, un pod compromesso può comunque sniffare il traffico o attaccare altri servizi.

D: Penetrify supporta Kubernetes gestiti come EKS o GKE?

R: Sì. Poiché Penetrify è cloud-native, è progettato per integrarsi con i principali provider cloud. Si concentra sulle vulnerabilità che esistono indipendentemente dal fatto che il cluster sia autogestito o gestito.

Takeaway Azionabili: il tuo piano di sicurezza di 30 giorni

Se ti senti sopraffatto, non cercare di fare tutto in una volta. Dividilo in una roadmap mensile.

Settimana 1: Visibilità e Baseline

• Esegui un audit di configurazione (prova a utilizzare kube-bench o polaris).
• Elenca ogni singolo ClusterRole e vedi chi ha accesso cluster-admin.
• Abilita la registrazione degli audit per il tuo control plane.

Settimana 2: Riduzione della Surface Area

• Imposta automountServiceAccountToken: false per tutti i pod che non necessitano dell'accesso API.
• Implementa una network policy "Default Deny" nel tuo namespace di sviluppo.
• Aggiorna tutte le tue immagini di base alle ultime versioni stabili.

Settimana 3: Rafforzamento dell'Accesso

• Sostituisci tutti i container "privileged: true" con funzionalità specifiche.
• Sposta le tue password sensibili da K8s Secrets a un secret manager.
• Imposta una policy di Pod Security Admission per bloccare i container root.

Settimana 4: Convalida e Test

• È qui che smetti di indovinare e inizi a sapere. Pianifica un cloud pentest tramite Penetrify per vedere se le modifiche apportate nelle settimane 1-3 hanno effettivamente funzionato.
• Utilizza i risultati di quel pentest per creare un backlog di correzioni di sicurezza per il mese successivo.

Considerazioni finali

Kubernetes è una bestia. Ci dà un potere incredibile, ma quel potere comporta molta complessità. L'errore più grande che puoi fare è presumere che "complesso" significhi "sicuro". In realtà, la complessità è spesso dove si nascondono le vulnerabilità.

Proteggere il tuo cluster non è un progetto una tantum; è un'abitudine. Si tratta di passare da una mentalità di "Spero che siamo al sicuro" a "So che siamo al sicuro perché ho cercato di romperlo". Combinando RBAC rigoroso, network policies rigide e cloud pentesting regolari, puoi godere dei vantaggi di Kubernetes senza rimanere sveglio la notte chiedendoti se un singolo file YAML configurato in modo errato farà crollare la tua attività.

Se sei pronto a smettere di indovinare, è il momento di mettere alla prova la tua infrastruttura. Che tu sia un piccolo team o una grande impresa, l'obiettivo è lo stesso: trovare i buchi prima che lo facciano i cattivi. Una piattaforma come Penetrify rende questo processo gestibile, scalabile e, soprattutto, attuabile. Non aspettare una violazione per scoprire dove sono le tue debolezze. Anticipa oggi stesso.