Kubernetes non risolve i problemi di sicurezza delle tue applicazioni—piuttosto, aggiunge uno strato di orchestrazione al di sopra di essi. Ogni cluster introduce un piano di controllo, un runtime di nodo, un modello di identità, una rete software-defined e un archivio di segreti, ognuno con le proprie modalità di fallimento. Un singolo RoleBinding eccessivamente permissivo o un pod privileged: true può trasformare un bug web a bassa gravità in un completo takeover del cluster, e da lì in una compromissione dell'account cloud sottostante.
Questa guida illustra come testare effettivamente un ambiente Kubernetes: la superficie di attacco, le misconfigurazioni che emergono in quasi ogni audit, i vettori di fuga dei container che trasformano un pod compromesso in root sul nodo, e come le tre discipline—image scanning, runtime testing e cluster pentesting—si integrano tra loro.
La Superficie di Attacco di Kubernetes
Prima di testare, mappa ciò che vede un attaccante. Un cluster Kubernetes espone quattro componenti di alto valore, e ognuno è un obiettivo distinto con modalità di fallimento distinte.
L'API server
Il kube-apiserver è la porta d'accesso a tutto. Ogni comando kubectl, ogni controller, ogni workload che comunica con il cluster passa attraverso di esso. Testare l'API server significa verificare che l'accesso anonimo sia disabilitato, che l'autenticazione sia applicata (non solo l'autorizzazione RBAC dietro una porta aperta), che i flag --anonymous-auth=false e audit-logging siano impostati, e che l'endpoint non sia inutilmente esposto a internet pubblico. Un numero sorprendente di cluster gestiti e self-hosted lasciano ancora l'API server raggiungibile da qualsiasi luogo con la sola protezione basata su token.
Il kubelet
Ogni nodo esegue un kubelet, che espone un'API (porta predefinita 10250) per la gestione dei pod su quel nodo. Se il kubelet consente l'accesso non autenticato o di sola lettura (la porta legacy 10255), un attaccante che raggiunge un nodo—o un pod che può instradare a uno—può enumerare i pod in esecuzione, leggere il loro ambiente e, nei cluster mal configurati, eseguire comandi all'interno dei container. Il kubelet è il classico punto di pivot che kube-hunter sonda.
etcd
etcd è il database del cluster. Memorizza ogni oggetto, inclusi i Secrets, in chiaro a meno che la crittografia a riposo non sia esplicitamente abilitata. L'accesso diretto a etcd è equivalente a cluster-admin: è possibile leggere ogni credenziale e riscrivere lo stato del cluster. Il testing verifica che etcd sia raggiungibile solo dal piano di controllo, richieda mutual TLS e abbia --encryption-provider-config configurato in modo che i Secrets non siano in chiaro.
RBAC e identità
Il controllo degli accessi basato sui ruoli è il tessuto connettivo. Decide quali soggetti possono accedere a quali risorse. Poiché RBAC è additivo e facile da concedere in eccesso, è la fonte più comune di percorsi di privilege-escalation nei cluster reali—trattato in dettaglio di seguito.
Misconfigurazioni Comuni del Cluster
La frase kubernetes cluster security misconfiguration copre un insieme prevedibile di schemi. Questi sono i risultati che appaiono in quasi ogni prima valutazione, classificati approssimativamente in base alla frequenza con cui portano a una reale compromissione.
Pod privilegiati e con capacità eccessive
Un pod con securityContext.privileged: true ha un accesso effettivamente illimitato all'host. Anche senza pieno privilegio, capacità pericolose come CAP_SYS_ADMIN, allowPrivilegeEscalation: true, o l'esecuzione come UID 0, danno a un attaccante molto più di quanto il workload necessiti. La soluzione è un contesto di sicurezza restrittivo applicato ovunque:
Mount hostPath e namespace condivisi
Un volume hostPath monta una directory dal nodo nel pod. Montare /, /var/run/docker.sock o /etc/kubernetes consente al container di leggere o scrivere il filesystem dell'host—una fuga immediata. Lo stesso vale per hostPID, hostNetwork e hostIPC, che rompono il confine di isolamento tra pod e nodo. Il testing segnala qualsiasi workload che richieda questi elementi, a meno che non ci sia una ragione documentata e verificata (ad esempio, un CNI o un DaemonSet di monitoraggio).
Token di service account predefiniti
Per impostazione predefinita, ogni pod riceve il token del service account default del namespace montato in /var/run/secrets/kubernetes.io/serviceaccount/token. Se quel service account ha permessi RBAC significativi—o se il workload non necessita affatto di accesso alle API—il token è materiale credenziale gratuito per chiunque comprometta il pod. Impostare automountServiceAccountToken: false sui workload che non chiamano le API e definire l'ambito per quelli che lo fanno.
NetworkPolicies mancanti
Di default, il networking di Kubernetes è piatto: qualsiasi pod può raggiungere qualsiasi altro pod in qualsiasi namespace. Senza NetworkPolicies, un singolo pod front-end compromesso può comunicare direttamente con il tuo database, i tuoi servizi di amministrazione interni e l'endpoint dei metadati del cloud. Una policy di default-deny per namespace, con regole di allow esplicite, è la base:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Secret non crittografati e metadati esposti
I Secret di Kubernetes sono codificati in base64, non crittografati. Senza la crittografia di etcd a riposo, sono leggibili da chiunque abbia accesso a etcd o ai backup. A peggiorare la situazione, i pod che possono raggiungere il servizio di metadati dell'istanza cloud (169.254.169.254) possono spesso rubare le credenziali del ruolo IAM del nodo—il ponte dalla compromissione del cluster alla compromissione dell'account cloud.
RBAC: Chi può fare cosa
Il RBAC di Kubernetes controlla l'accesso alle risorse del cluster tramite Ruoli, ClusterRuoli, RoleBindings e ClusterRoleBindings. Un buon testing va oltre il "c'è qualcosa legato a cluster-admin" e cerca i percorsi di escalation—catene di permessi apparentemente ragionevoli che si combinano in un controllo completo.
I verbi da tenere d'occhio sono escalate, bind e impersonate. Un soggetto che può create pod può spesso montare un service account privilegiato e leggerne il token. Un soggetto che può bind ruoli può concedersi cluster-admin. Un soggetto con impersonate può agire come qualsiasi utente. Altri percorsi classici includono la capacità di leggere Secret a livello di cluster, di creare o modificare ValidatingWebhookConfigurations (intercettando ogni richiesta API) o di eseguire comandi in pod in esecuzione con privilegi più elevati.
Il testing RBAC pratico risponde: qualche service account predefinito detiene permessi di cui non ha bisogno? Un soggetto con ambito di namespace può raggiungere risorse con ambito di cluster? Ci sono regole wildcard (resources: ["*"], verbs: ["*"])? Strumenti come rbac-tool e kubectl-who-can aiutano a enumerare questi elementi, ma interpretare se una catena sia effettivamente sfruttabile è dove il testing avversario dimostra il suo valore.
Testing di Fuga dal Container
La classe più critica di vulnerabilità riscontrata in Kubernetes è la vulnerabilità di escape del container—ovvero la capacità di uscire da un container per accedere al nodo host, e poi usare questo punto d'appoggio per il movimento laterale. Questo è il fulcro del problema di sicurezza Docker legato alla vulnerabilità di escape del container, e si applica indipendentemente dal fatto che il tuo runtime sia containerd, CRI-O o Docker.
I vettori di escape rientrano in due categorie. La prima è guidata dalla configurazione: al container è stato concesso un accesso sufficiente per uscirne. Un /var/run/docker.sock scrivibile consente a un container di creare un nuovo container privilegiato sull'host. Un pod privilegiato può montare il filesystem root dell'host e scrivere una chiave SSH o un cron job. hostPID espone i processi dell'host per l'iniezione. Questi sono gli escape comuni, ad alta probabilità, e si mappano direttamente alle misconfigurazioni sopra menzionate.
La seconda categoria è guidata da exploit: CVE del kernel e del runtime. Esempi storici come CVE-2019-5736 (sovrascrittura di runc /proc/self/exe) e vari bug di cgroups e del kernel consentono a un attaccante di evadere anche da un container ragionevolmente configurato. Testare qui significa sapere quali versioni di runtime e kernel si utilizzano, confrontarle con le CVE di escape note e confermare che i controlli di difesa in profondità (seccomp, AppArmor/SELinux, gVisor o Kata per carichi di lavoro ad alto rischio) siano effettivamente applicati anziché impostati su Unconfined.
Una kill chain realistica: un bug SSRF in un carico di lavoro web raggiunge l'endpoint dei metadati del cloud → ruba il ruolo IAM del nodo → il ruolo può estrarre da un registro di container e l'account di servizio del pod può elencare i Secret → un Secret contiene un kubeconfig di cluster-admin → l'attaccante pianifica un pod privilegiato su ogni nodo. Ogni passaggio è banale. In concatenazione, è la fine del gioco. Questo è proprio il tipo di percorso a più passaggi che gli scanner automatici a problema singolo non rilevano.
Scansione della Sicurezza dei Container vs Testing del Runtime vs Penetration Testing del Cluster
I team spesso chiedono quale strumento "si occupa della sicurezza di Kubernetes". La risposta onesta è che ci sono tre diverse discipline, rispondono a domande diverse e un programma maturo le esegue tutte e tre. Comprendere la differenza tra scansione della sicurezza dei container e testing del runtime—e dove si colloca il Penetration Testing del cluster—è la chiave per non sprecare il budget in coperture sovrapposte lasciando al contempo lacune reali.
| Dimensione | Scansione immagini | Test in runtime | Penetration Testing del cluster |
|---|---|---|---|
| Domanda a cui risponde | Questa immagine contiene pacchetti con vulnerabilità note? | Il carico di lavoro in esecuzione si sta comportando in modo sicuro in questo momento? | Un attaccante può effettivamente compromettere il cluster? |
| Quando viene eseguito | Build / registry / gate CI | Continuamente, nel cluster live | Puntuale, avversario |
| Cosa ispeziona | Livelli immagine, pacchetti OS, librerie, Dockerfile | Syscalls, comportamento dei processi, flussi di rete, drift | RBAC, percorsi di fuga, movimento laterale, exploit dei carichi di lavoro |
| Rileva | CVE, dipendenze obsolete, segreti nei livelli | Anomalie, crypto-miner, egress inatteso | Percorsi di attacco concatenati e sfruttabili end-to-end |
| Mancanze | Configurazione in runtime, RBAC, difetti logici | Errori di configurazione latenti non ancora attivati | Problemi al di fuori della finestra di test |
| Strumenti di esempio | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, Penetration Test manuale, Penetrify |
| Idoneità all'automazione | Completamente automatizzabile in CI | Agente sempre attivo | Pianificato + continuo basato su AI |
La scansione delle immagini è economica, veloce e dovrebbe far parte di ogni pipeline—ma un'immagine perfettamente scansionata può comunque essere eseguita come root con un mount hostPath se glielo si permette. Il test in runtime rileva ciò che sta accadendo, ma dice poco su ciò che potrebbe accadere. Il Penetration Testing del cluster è l'unico dei tre che dimostra la sfruttabilità concatenando i risultati nel modo in cui farebbe un attaccante. Nessuno sostituisce gli altri.
Strumenti: kube-bench, kube-hunter e Trivy
Un solido workflow di scansione della sicurezza dei container per Kubernetes di solito combina tre strumenti open-source fondamentali, ognuno con un ruolo chiaro. Sono complementari, non in competizione.
kube-bench
kube-bench esegue il CIS Kubernetes Benchmark sui tuoi nodi e sul control plane. È un auditor di configurazione: controlla i flag del server API, le impostazioni di kubelet, i permessi dei file sui componenti del cluster e la configurazione di etcd rispetto a uno standard di hardening ben noto. Eseguilo su ogni nodo e in CI rispetto ai manifest del tuo cluster. Ti dice se il tuo cluster è costruito secondo le specifiche; non ti dice se le specifiche sono sotto attacco.
kube-hunter
kube-hunter è uno strumento di ricognizione attiva. Puntato verso un cluster (o eseguito come pod al suo interno), sonda kubelet esposti, endpoint API accessibili, il servizio di metadati e punti deboli noti, quindi riporta ciò che un attaccante potrebbe scoprire. È più vicino a uno scanner di rete per Kubernetes che a un Penetration Test completo—eccellente per la mappatura della superficie, limitato per dimostrare l'exploit end-to-end.
Trivy
Trivy è lo scanner "coltellino svizzero": CVE delle immagini container, scansione di errori di configurazione di manifest IaC e Kubernetes, segreti esposti e generazione di SBOM. È la scelta naturale per la colonna "Scansione immagini" di cui sopra e si integra perfettamente nelle pipeline di build. Abbinalo a kube-bench per la copertura della configurazione e a kube-hunter per la ricognizione live, e avrai una solida base open-source.
Ciò che questo trio non fa è ragionare sulla logica della tua applicazione, concatenare un bug a livello web in una presa di controllo del cluster, o adattare il suo approccio come farebbe un attaccante umano. Questo è il divario che la prossima sezione affronta. Per integrare questi scanner nella tua pipeline di delivery, consulta la nostra guida su CI/CD Penetration Testing e automazione della sicurezza della pipeline.
Il Livello Web e API del Carico di Lavoro
Ecco la parte che la maggior parte dei programmi di sicurezza Kubernetes sottovaluta: i carichi di lavoro stessi. Il tuo cluster ospita applicazioni web e API, ed è da lì che di solito proviene il punto d'appoggio iniziale. Un attaccante raramente inizia con un kubeconfig rubato—inizia con un SSRF, un bypass di autenticazione, o un bug di injection in un servizio che hai distribuito, e poi si sposta nel cluster usando le misconfigurazioni di cui sopra.
È esattamente qui che si inserisce il Penetration Testing autonomo basato su AI. Gli scanner di configurazione e i benchmark CIS non possono trovare un bypass di autenticazione della logica di business nel tuo servizio di checkout; non sono mai stati progettati per farlo. Il testing basato su AI esercita gli endpoint web e API in esecuzione all'interno dei tuoi carichi di lavoro nel modo in cui farebbe un attaccante—sondando autenticazione, autorizzazione, injection e SSRF—e poi segue la catena: da un bug del carico di lavoro, al token dell'account di servizio montato, alle autorizzazioni del cluster che quel token sblocca, al ruolo IAM del cloud dietro il nodo.
Questa copertura continua, che concatena gli exploit, del livello applicativo completa—piuttosto che sostituire—la tua pipeline kube-bench e Trivy. Per la dimensione specifica delle API, il nostro approfondimento su l'automazione del testing di sicurezza delle API copre l'OWASP API Top 10 e come rendere quel testing ripetibile tra le distribuzioni.
Se stai ancora mappando quali carichi di lavoro e cluster prioritizzare, il post correlato sul testing di sicurezza dei container per immagini Docker e protezione runtime copre più in dettaglio i lati dell'immagine e del runtime, e la nostra guida alla risoluzione delle misconfigurazioni comuni nei cluster Kubernetes fornisce passaggi di remediation concreti per i problemi di cui sopra.
Testing di Kubernetes con Penetrify
Il testing di sicurezza Kubernetes di Penetrify copre RBAC, sicurezza dei pod, policy di rete, gestione dei segreti, vettori di fuga dei container e configurazioni Kubernetes gestite (EKS, AKS, GKE). Il testing valuta sia il livello Kubernetes che il livello di integrazione del cloud provider—perché una compromissione di Kubernetes spesso porta alla compromissione dell'account cloud tramite account di servizio collegati e ruoli IAM.
La differenza di costo è il motivo per cui i team lo automatizzano. Un tradizionale Penetration Test manuale di Kubernetes da parte di una società di consulenza costa tipicamente da $5.000 a $50.000 per incarico e ti fornisce un'istantanea puntuale che diventa obsoleta nel momento in cui rilasci la tua prossima distribuzione. Penetrify funziona continuamente da $100 a $5.000 al mese, rieseguendo il testing ogni volta che il tuo cluster cambia. Per una ripartizione più completa di ciò che determina questi numeri, consulta il nostro confronto dei costi del Penetration Testing.
In Sintesi
Kubernetes aggiunge un intero livello di orchestrazione di superficie di attacco alla tua infrastruttura cloud. Testarlo richiede tre discipline complementari—scansione delle immagini, monitoraggio del runtime e cluster Penetration Testing—oltre a test avversari dei carichi di lavoro web e API che offrono agli attaccanti il loro primo punto d'appoggio. Gli scanner di configurazione rafforzano la build; solo il pentesting che concatena gli exploit dimostra ciò che un attaccante può effettivamente raggiungere.
Penetrify combina il pentesting autonomo basato su AI dei tuoi carichi di lavoro con test di integrazione del cluster e del cloud, in modo continuo e a partire da $100/mese—così la tua sicurezza Kubernetes tiene il passo con ogni deployment invece che con ogni audit annuale.