Come proteggere i cluster Kubernetes con il Cloud Penetration Testing

Kubernetes è praticamente diventato il sistema operativo del cloud. Se esegui container su larga scala, quasi certamente utilizzi K8s. È potente, flessibile e gestisce l'orchestrazione in modo impeccabile. Ma ecco il punto: quella stessa potenza comporta un'enorme quantità di complessità. Quando passi da una configurazione tradizionale basata su VM a un livello di orchestrazione containerizzato, la tua superficie di attacco non si limita a spostarsi, ma si espande in direzioni che potresti non considerare.

La maggior parte dei team inizia il proprio percorso Kubernetes seguendo alcuni tutorial di base, avviando un cluster su EKS, GKE o AKS e distribuendo le proprie app. Tutto funziona. Quindi, aggiungono alcuni namespace, alcuni controller di ingresso e forse un controllo degli accessi basato sui ruoli (RBAC) di base. Sembra sicuro. Ma "funziona" ed "è sicuro" sono due cose molto diverse nel mondo dell'infrastruttura cloud-native. Un singolo file YAML configurato in modo errato o un ServiceAccount con privilegi eccessivi può fare la differenza tra un ambiente di produzione sicuro e una totale acquisizione del cluster.

È qui che entra in gioco il cloud pentesting. Non puoi semplicemente eseguire uno scanner di rete standard su un cluster Kubernetes e considerarlo sufficiente. K8s ha la sua rete interna, il suo server API e il suo set di stranezze nella gestione delle identità. Per proteggere effettivamente un cluster, devi pensare come un attaccante. Devi chiederti: "Se comprometto un pod, posso raggiungere il server API? Posso rubare un token dal filesystem? Posso spostarmi lateralmente in un altro namespace?"

In questa guida, approfondiremo la realtà della protezione di Kubernetes. Andremo oltre il generico consiglio "usa password complesse" ed esamineremo i vettori di attacco reali che tengono svegli di notte gli ingegneri della sicurezza. Soprattutto, esploreremo come un approccio cloud-native al Penetration Testing, come quello che abbiamo creato in Penetrify, ti consente di trovare questi buchi prima che lo faccia qualcun altro.

Comprendere la superficie di attacco di Kubernetes

Prima di parlare di come testare il cluster, dobbiamo capire cosa stiamo effettivamente testando. Kubernetes non è una singola cosa; è una raccolta di componenti che devono comunicare tra loro. Se uno qualsiasi di questi canali di comunicazione è aperto o autenticato in modo improprio, l'intero castello di carte può crollare.

Il piano di controllo: il cervello del cluster

Il piano di controllo è l'obiettivo principale per qualsiasi attaccante serio. Perché? Perché se controlli il server API, controlli tutto. Il kube-apiserver è il gateway per tutte le attività amministrative. Se è esposto alla rete internet pubblica senza un'autenticazione rigorosa, o se c'è una vulnerabilità nella versione che stai eseguendo, un attaccante può essenzialmente inviare comandi al tuo cluster come se fosse l'amministratore.

Poi c'è etcd. Questo è il database del cluster. Memorizza tutto: segreti, mappe di configurazione e lo stato di ogni pod. Se un attaccante ottiene l'accesso a etcd, non ha nemmeno bisogno di parlare con il server API; può semplicemente leggere i tuoi segreti direttamente dal disco.

I nodi worker e il Kubelet

I nodi worker sono dove viene eseguito il tuo codice effettivo. Il kubelet è l'agente in esecuzione su ciascun nodo che comunica con il piano di controllo. Un errore comune è lasciare l'API Kubelet aperta o consentire l'accesso non autenticato. Se posso parlare con un Kubelet, potrei essere in grado di eseguire comandi all'interno di un pod o persino estrarre informazioni sensibili sull'ambiente del nodo.

I pod e i container

Questo è il punto di ingresso più comune. La maggior parte degli attacchi inizia con una vulnerabilità nel codice dell'applicazione, forse un RCE in stile Log4j o una semplice SQL Injection. Una volta che l'attaccante è all'interno di un container, inizia a "pod escaping". Cerca modi per uscire dal container e passare al nodo host sottostante. Da lì, cercano il token ServiceAccount solitamente montato in /var/run/secrets/kubernetes.io/serviceaccount/token.

Il livello di rete (CNI)

La rete Kubernetes è spesso una rete "flat" per impostazione predefinita. Ciò significa che, per impostazione predefinita, qualsiasi pod nel cluster può comunicare con qualsiasi altro pod, indipendentemente dal namespace. Se il tuo web server frontend è compromesso, può potenzialmente inviare richieste alla tua API di elaborazione dei pagamenti interna o al tuo database senza alcun firewall one-stop in mezzo.

Errori di configurazione comuni di Kubernetes che portano a violazioni

Quando eseguiamo Penetration Testing presso Penetrify, raramente troviamo vulnerabilità "Zero Day" nel codice core di Kubernetes. Invece, troviamo errori "Zero Day" nel modo in cui il cluster è stato configurato. Questi sono i frutti a portata di mano che gli attaccanti amano.

Ruoli RBAC con privilegi eccessivi

Il controllo degli accessi basato sui ruoli (RBAC) è la parte più incompresa della sicurezza di K8s. È molto facile frustrarsi con gli errori "Autorizzazione negata" durante la distribuzione e semplicemente assegnare a un ServiceAccount il ruolo di cluster-admin.

Immagina un semplice pod di monitoraggio che ha solo bisogno di elencare i pod per verificarne lo stato. Se a quel pod vengono concesse le autorizzazioni di cluster-admin e l'applicazione al suo interno viene compromessa, l'attaccante ha ora il pieno controllo dell'intero cluster. Può eliminare i namespace, rubare i segreti e distribuire i propri pod dannosi (come i crypto miner).

La trappola del container "Privileged"

Eseguire un container come privileged: true dice fondamentalmente a Kubernetes di disabilitare la maggior parte dei confini di sicurezza tra il container e l'host. Un container privilegiato ha quasi lo stesso accesso al kernel host di un processo in esecuzione direttamente sul nodo. Per un pentester, un container privilegiato è un biglietto d'oro. Rende banale la fuga verso l'host, consentendo loro di accedere al socket Docker o all'API Kubelet.

Dashboard e server API esposti

La dashboard di Kubernetes è ottima per la visibilità, ma è un incubo se non è protetta. Abbiamo visto cluster in cui la dashboard era esposta a Internet con un account di servizio predefinito che aveva privilegi amministrativi. È essenzialmente una GUI basata sul web per distruggere la propria infrastruttura. Allo stesso modo, lasciare l'API server aperto a 0.0.0.0/0 senza MFA o una rigida whitelisting IP è una ricetta per il disastro.

Segreti non protetti

Molti team archiviano i "segreti" negli oggetti Kubernetes Secrets. Anche se sembra giusto, ricorda che, per impostazione predefinita, i segreti K8s sono solo codificati in base64, non crittografati. Chiunque abbia accesso all'API o al database etcd può decodificarli in pochi secondi. Se non stai utilizzando un KMS (Key Management Service) dedicato o uno strumento come HashiCorp Vault, i tuoi segreti non sono realmente segreti.

Il flusso di lavoro del Cloud Penetration Testing per Kubernetes

Il Penetration Testing tradizionale è spesso un evento "puntuale": un consulente arriva per due settimane, scrive un report e se ne va. Ma gli ambienti Kubernetes cambiano ogni volta che esegui kubectl apply. Hai bisogno di un approccio al testing più continuo e cloud-native.

Fase 1: Ricognizione e mappatura esterna

Il primo passo in un cloud pentest è vedere ciò che il mondo vede. Iniziamo scansionando gli endpoint esposti.

L'API server è raggiungibile?
C'è una porta Kubelet (10250) aperta?
Ci sono dashboard esposte o pagine di metriche Prometheus?
Quali regole di ingresso consentono il traffico nel cluster?

Fase 2: Accesso iniziale (l'"impronta")

Una volta trovato un punto di ingresso, ad esempio un'app web vulnerabile, stabiliamo un punto d'appoggio. Questo di solito comporta l'ottenimento di una reverse shell. Ma una volta entrati, l'obiettivo cambia da "attaccare l'app" a "attaccare il cluster".

La prima cosa che fa un pentester è controllare il token ServiceAccount: cat /var/run/secrets/kubernetes.io/serviceaccount/token

Se quel token esiste, possiamo usarlo per autenticarci all'API server dall'interno del pod.

Fase 3: Enumerazione interna e Privilege Escalation

Ora chiediamo: "Cosa posso effettivamente fare con questo token?" Usiamo strumenti come kubectl auth can-i --list per vedere le nostre autorizzazioni.

Se abbiamo i permessi per create pods, possiamo lanciare un pod "dannoso" che monta il filesystem root dell'host. Se abbiamo i permessi per get secrets, possiamo scaricare ogni password e chiave API nel namespace. È qui che avviene la "partita a scacchi" della sicurezza di Kubernetes: passare da un pod con privilegi bassi a un nodo con privilegi elevati.

Fase 4: Movimento laterale

Se il cluster non ha Network Policies (la versione K8s di un firewall), possiamo muoverci lateralmente. Scansioniamo la rete interna dei pod per trovare altri servizi. Potremmo trovare una cache Redis non autenticata o un database interno che si fida di qualsiasi connessione proveniente dall'interno del cluster.

Fase 5: Esfiltrazione e persistenza

La fase finale consiste nel vedere se possiamo rubare dati o mantenere l'accesso. Possiamo creare un Deployment "backdoor" che si riavvia se viene eliminato? Possiamo rubare i metadati IAM del provider cloud dal nodo (ad esempio, accedendo a 169.254.169.254 su AWS) per spostarci dal cluster Kubernetes all'account AWS più ampio?

Passaggi pratici per proteggere il tuo cluster

Se hai letto fin qui e stai pensando: "Il mio cluster potrebbe essere vulnerabile", non farti prendere dal panico. La sicurezza è un processo di miglioramento continuo. Ecco una checklist pratica per spostare il tuo cluster da "standard" a "protetto".

1. Implementa Network Policies rigorose

Smetti di presumere che la rete interna sia sicura. Per impostazione predefinita, implementa una politica "deny-all" sia per il traffico in entrata che in uscita all'interno dei tuoi namespace. Quindi, consenti esplicitamente solo le connessioni necessarie.

Il Pod A dovrebbe parlare solo con il Pod B sulla porta 8080.
Il Pod B dovrebbe parlare solo con il database sulla porta 5432.
Blocca tutti i pod che parlano con l'API dei metadati del cloud a meno che non ne abbiano assolutamente bisogno.

2. Pulisci il tuo RBAC

Controlla i tuoi ruoli. Smetti di usare cluster-admin per tutto.

Usa Namespaced Roles invece di ClusterRoles quando possibile.
Segui il principio del minimo privilegio (PoLP). Se un pod ha solo bisogno di leggere un ConfigMap, non dargli la possibilità di aggiornarlo.
Controlla regolarmente chi ha accesso al cluster utilizzando strumenti come rbac-lookup.

3. Usa Pod Security Admissions (PSA)

Smetti di consentire container con privilegi. Kubernetes ha Pod Security Admissions integrati che ti consentono di applicare diversi livelli di sicurezza:

Privileged: senza restrizioni (praticamente "fai quello che vuoi"). Evita questo in produzione.
Baseline: previene note Privilege Escalation.
Restricted: applica uno standard di sicurezza molto elevato (nessun utente root, nessun accesso alla rete host).

Punta al profilo restricted per tutti i tuoi carichi di lavoro applicativi.

4. Proteggi i tuoi segreti

Allontanati dai segreti K8s codificati in base64.

Abilita la Encryption at Rest per il tuo database etcd.
Usa un secret manager cloud-native. Ad esempio, usa AWS Secrets Manager o Azure Key Vault e integrali con i tuoi pod usando il Secret Store CSI Driver. Ciò garantisce che i segreti vengano iniettati nel pod in fase di esecuzione e mai archiviati come testo normale nell'API K8s.

5. Mantieni aggiornati i tuoi componenti

Sembra basilare, ma è qui che avvengono molte violazioni. Le vulnerabilità in kube-apiserver o kubelet vengono corrette rapidamente, ma se stai eseguendo una versione di due anni fa, sei un bersaglio facile. Automatizza gli aggiornamenti del tuo cluster per rimanere aggiornato con le ultime patch di sicurezza.

Un confronto: Penetration Testing manuale vs. scansione automatizzata vs. piattaforme Cloud-Native

Molte persone chiedono: "Non posso semplicemente eseguire uno scanner di vulnerabilità?" La risposta è sì, ma uno scanner non è un Penetration Test. Ecco la differenza.

Feature	Automated Vulnerability Scanner	Traditional Manual Pentest	Cloud-Native Platform (Penetrify)
Scope	Finds known CVEs in packages.	Analisi approfondita della logica e della configurazione.	Combina la scansione di CVE con l'analisi della configurazione.
Context	Doesn't understand RBAC or network flow.	Comprende il contesto ma è lento.	Mappa la superficie di attacco in tempo reale.
Frequency	Can run daily.	Una o due volte l'anno.	Continuo e su richiesta.
Actionability	Gives a long list of "potential" bugs.	Fornisce un report dettagliato.	Fornisce percorsi di correzione e si integra con SIEM.
Cost	Low to Moderate.	Alto (costi di consulenza).	Abbonamento scalabile.

Gli scanner di vulnerabilità sono ottimi per trovare una versione di Nginx che ha un bug. Ma uno scanner non ti dirà che la tua policy RBAC consente al pod di uno sviluppatore di eliminare il tuo database di produzione. Un Penetration Tester manuale lo troverà, ma è costoso e non può essere ovunque contemporaneamente.

Una piattaforma come Penetrify colma questa lacuna. Utilizza un'architettura cloud-native per simulare questi attacchi automaticamente e costantemente, offrendoti la profondità di un Penetration Test con la velocità di uno scanner.

Scenario avanzato: la fuga "Pod-to-Cloud"

Per capire veramente perché il cloud pentesting è diverso, esaminiamo uno scenario di attacco realistico. Questo è un percorso comune che troviamo durante le valutazioni.

Passaggio 1: L'ingresso Un aggressore trova una vulnerabilità Server-Side Request Forgery (SSRF) in un'applicazione Django rivolta al pubblico in esecuzione in un pod Kubernetes.

Passaggio 2: L'hit dei metadati L'aggressore utilizza l'SSRF per raggiungere l'endpoint dei metadati del provider cloud: http://169.254.169.254/latest/meta-data/iam/security-credentials/. Poiché il ruolo IAM del nodo è sovra-privilegiato, l'aggressore recupera una chiave di accesso temporanea di AWS.

Passaggio 3: Scansione dell'account Utilizzando tali chiavi, l'aggressore si rende conto di avere le autorizzazioni S3:ListBucket e S3:GetObject per l'intero account AWS. Trovano un bucket contenente backup del database di produzione.

Passaggio 4: Acquisizione del cluster Mentre esamina il bucket S3, trova un backup di un file kubeconfig che è stato caricato accidentalmente. Questo file contiene un certificato per un utente cluster-admin.

Passaggio 5: Controllo totale L'aggressore utilizza il kubeconfig per connettersi all'API server dal proprio laptop. Ora hanno il potere assoluto sul cluster. Distribuiscono un tunnel crittografato (come Ngrok) all'interno del cluster per mantenere una backdoor permanente, bypassando tutti i firewall perimetrali.

La lezione? La vulnerabilità non era solo nell'app Django. Era una catena: SSRF $\rightarrow$ IAM del nodo sovra-privilegiato $\rightarrow$ Segreto trapelato in S3 $\rightarrow$ Kubeconfig amministratore. Un semplice scanner di pod avrebbe trovato solo la vulnerabilità di Django; non ti avrebbe mostrato che il tuo intero account AWS era a rischio.

Integrazione della sicurezza nella pipeline CI/CD (DevSecOps)

Non puoi semplicemente "fare" sicurezza alla fine. Quando un Penetration Tester trova una falla nel tuo cluster di produzione, il danno (o il costo per risolverlo) è già alto. Devi spostare la sicurezza "a sinistra".

Test Shift-Left

Integra i controlli di sicurezza nelle tue pipeline GitLab o GitHub.

Analisi statica (SAST): scansiona i tuoi Dockerfile per "USER root" e i tuoi file YAML per privileged: true.
Image Scanning: utilizza strumenti per assicurarti che le tue immagini di base non abbiano CVE noti prima che raggiungano il registro.
Policy as Code: utilizza OPA (Open Policy Agent) o Kyverno. Questi strumenti fungono da admission controller. Se uno sviluppatore tenta di distribuire un pod che non ha limiti di risorse o è in esecuzione come root, il cluster rifiuta semplicemente la distribuzione.

Il ciclo di feedback

La vera magia accade quando ricolleghi i risultati del tuo Penetration Testing al tuo ciclo di sviluppo. Quando una piattaforma come Penetrify identifica una configurazione errata nel tuo cluster di sviluppo, tale informazione dovrebbe creare automaticamente un ticket in Jira affinché il team lo corregga.

La sicurezza non dovrebbe essere un "cancello" che ferma la distribuzione; dovrebbe essere un "guardrail" che guida la distribuzione. Quando gli sviluppatori sanno esattamente perché una certa configurazione è pericolosa (perché un Penetration Test ha simulato un attacco e lo ha dimostrato), è molto più probabile che scrivano codice sicuro fin dall'inizio.

Errori comuni quando si protegge Kubernetes

Anche i team esperti inciampano su questi. Se stai gestendo un cluster, controlla se stai facendo una di queste cose.

Errore 1: Fidarsi dell'etichetta "Cloud Managed"

Molte persone presumono che, poiché utilizzano EKS o GKE, Google o Amazon si occupino della sicurezza. Mentre il provider cloud protegge il control plane (i nodi master), tu sei comunque responsabile del data plane (i tuoi nodi worker, i tuoi pod e le tue policy di rete). Il "Shared Responsibility Model" è reale. Se lasci aperto il tuo API server, AWS non impedirà a un aggressore di entrare.

Errore 2: Ignorare il namespace "Default"

Il namespace default è spesso un ricettacolo per test e pod casuali. Molti team si dimenticano di applicare le stesse rigide policy RBAC e di rete al namespace default come fanno per l'ambiente di production. Un attaccante che entra in un pod di "test" nel namespace predefinito può spesso usarlo come punto di partenza per attaccare altre parti del cluster.

Errore 3: Eccessiva Fiducia nella Scansione delle Immagini

Scansionare un'immagine alla ricerca di CVE è importante, ma non è sufficiente. Un'immagine può avere zero vulnerabilità note, ma essere comunque configurata per essere eseguita come root con accesso completo al namespace PID dell'host. Devi proteggere la configurazione di runtime, non solo il file binario.

Errore 4: Mancanza di Logging e Monitoraggio

Non puoi fermare un attacco che non puoi vedere. Molti team si dimenticano di abilitare i Kubernetes Audit Logs. I log di audit ti dicono chi ha fatto cosa, quando e come. Senza di essi, se un attaccante ruba un token e crea una backdoor, non avrai alcuna registrazione di come è successo.

FAQ: Proteggere Kubernetes con il Cloud Penetration Testing

D: Quanto spesso dovrei eseguire un Penetration Test sul mio cluster Kubernetes? R: Dipende dalla frequenza delle modifiche. Se rilasci codice quotidianamente, un Penetration Test una volta all'anno è inutile. Dovresti avere una scansione automatizzata giornaliera e Penetration Testing approfonditi ogni trimestre o dopo ogni importante modifica architetturale. Le piattaforme cloud-native consentono il "continuous pentesting", che è il gold standard.

D: Devo installare agenti sui miei nodi per il cloud pentesting? R: Non necessariamente. Molte piattaforme moderne, tra cui Penetrify, utilizzano una combinazione di scansione basata su API e "attacker pods" controllati per simulare le minacce senza la necessità di installare agenti invasivi su ogni singolo nodo. Ciò riduce il sovraccarico delle prestazioni e il rischio per la sicurezza dello strumento di test stesso.

D: Il pentesting può danneggiare il mio cluster di produzione? R: C'è sempre un rischio con qualsiasi test attivo. Questo è il motivo per cui consigliamo di testare in un ambiente di staging che rispecchia la produzione. Tuttavia, gli strumenti professionali di cloud pentesting sono progettati per essere non distruttivi. Cercano "proof of concept" di accesso (come la lettura di un file) piuttosto che eseguire attacchi di "denial of service".

D: Qual è la differenza tra una scansione delle vulnerabilità e un Penetration Test? R: Una scansione è come un sistema di sicurezza domestica che controlla se le porte sono chiuse a chiave. Un Penetration Test è come assumere qualcuno per cercare effettivamente di entrare in casa tua. Lo scanner ti dice che la porta potrebbe essere aperta; il pentester attraversa effettivamente la porta e ti dice che può raggiungere il tuo portagioie in camera da letto.

D: RBAC è sufficiente per proteggere un cluster? R: No. RBAC è solo uno strato. Hai anche bisogno di Network Policies (per fermare il movimento laterale), Pod Security Admissions (per fermare le evasioni) e Secret Management (per proteggere i dati sensibili). Pensalo come "defense in depth".

Conclusioni Finali e Prossimi Passi

Proteggere Kubernetes non significa spuntare una singola casella; si tratta di ridurre il "blast radius". Devi presumere che a un certo punto, un pod sarà compromesso. L'obiettivo è assicurarsi che, quando ciò accade, l'attaccante si trovi in una stanza chiusa a chiave senza chiavi e senza modo di parlare con il resto della casa.

Se ti senti sopraffatto, inizia con queste tre azioni immediate:

Controlla il tuo RBAC: trova ogni ServiceAccount con cluster-admin e scopri se ne ha effettivamente bisogno. (Suggerimento: probabilmente no).
Abilita le Network Policies: inizia bloccando tutto il traffico in uscita dai tuoi pod verso la cloud metadata API (169.254.169.254).
Esegui un test reale: smetti di indovinare se sei sicuro. Utilizza uno strumento o un servizio per simulare effettivamente un attacco.

La complessità di Kubernetes è la sua più grande forza, ma anche la sua più grande debolezza. L'unico modo per conoscere veramente la tua postura è testarla in condizioni reali.

Se vuoi smettere di indovinare e iniziare a sapere, Penetrify può aiutarti. Forniamo l'infrastruttura cloud-native per eseguire valutazioni di sicurezza di livello professionale senza l'enorme sovraccarico della consulenza tradizionale. Ti aiutiamo a trovare le lacune nel tuo RBAC, i buchi nelle tue network policies e i percorsi per l'escalation dei privilegi prima che lo faccia un attore malintenzionato.

Non aspettare una violazione per scoprire che il tuo cluster "sicuro" aveva una porta spalancata. Visita Penetrify.cloud oggi stesso e ottieni una visione chiara e attuabile della tua postura di sicurezza.

Torna al Blog