Pubblicato: 04-03-2026
Il team di ricerca sulla sicurezza cloud di KENSAI ha analizzato 12.000 cluster Kubernetes di produzione nelle aziende europee e ha scoperto che il 58% contiene configurazioni errate RBAC (Role-Based Access Control) sufficientemente gravi da consentire lo spostamento laterale e l'escalation dei privilegi all'amministratore del cluster. I cinque modelli più pericolosi (autorizzazioni con caratteri jolly, abuso dell'account di servizio predefinito, ClusterRoleBinding eccessivi, fuga dello spazio dei nomi tramite diritti di creazione di pod e montaggio di token in pod privilegiati) sono presenti nella maggior parte delle distribuzioni. La maggior parte delle organizzazioni non controlla i criteri RBAC dopo la configurazione iniziale.
⚡ Se un utente malintenzionato compromette qualsiasi pod nel 58% dei cluster scansionati, può passare all'amministratore completo del cluster in pochi minuti utilizzando solo le configurazioni errate RBAC.
L'errore di configurazione più diffuso: 23% dei cluster avere ClusterRoles personalizzati con verbi o risorse con caratteri jolly (*). Le squadre copiano il cluster-admin ruolo come punto di partenza e dimenticare di limitarlo. Un singolo pod con un account di servizio associato a tale ruolo ha accesso illimitato a ogni risorsa in ogni spazio dei nomi: segreti, mappe di configurazione, nodi e il server API stesso.
# Dangerous: Wildcard ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← Full cluster-admin equivalent
Ogni spazio dei nomi Kubernetes ha un default account di servizio che viene montato automaticamente nei pod a meno che non sia esplicitamente disabilitato. Nel 41% dei cluster, all'account di servizio predefinito in almeno uno spazio dei nomi sono state concesse autorizzazioni elevate, spesso perché un operatore ha eseguito un rapido kubectl create rolebinding durante il debug e non l'ho mai ripulito. Gli aggressori che ottengono RCE in qualsiasi pod in quello spazio dei nomi ereditano immediatamente tali autorizzazioni.
34% dei cluster avere più di 10 ClusterRoleBindings personalizzati, ovvero collegamenti che concedono autorizzazioni in tutti gli spazi dei nomi. Molti associano ruoli ampi a gruppi come system:authenticated o system:serviceaccounts, garantendo in modo efficace l'accesso elevato a ogni utente autenticato o a ogni account di servizio nel cluster.
Utenti con create pods l'autorizzazione in qualsiasi spazio dei nomi può montare il file system host, eseguire contenitori privilegiati o creare pod con qualsiasi account di servizio in quello spazio dei nomi. Nel 29% dei cluster, gli sviluppatori dispongono dei diritti di creazione dei pod senza l'applicazione degli standard di sicurezza dei pod, consentendo una banale fuga del contenitore verso il nodo sottostante.
Kubernetes monta i token dell'account di servizio nei pod per impostazione predefinita. Se combinati con specifiche pod privilegiate o accesso alla rete host, gli aggressori possono rubare il token ed autenticarsi sul server API dall'esterno del cluster. Solo il 12% dei cluster scansionati imposta automountServiceAccountToken: false su carichi di lavoro che non richiedono l'accesso API.
get secrets autorizzazione su tutti gli spazi dei nomi: l'aggressore ha estratto credenziali del database, chiavi API e certificati TLS entro 4 minuti.
Più della metà dei cluster Kubernetes di produzione analizzati contengono almeno un errore di configurazione RBAC che potrebbe consentire l'escalation dei privilegi da un pod compromesso all'accesso a livello di amministratore del cluster.
Nei test di penetrazione su cluster configurati in modo errato, il tempo medio dalla compromissione iniziale del pod all'accesso completo da parte dell'amministratore del cluster è stato di 3,2 minuti. Strumenti automatizzati come peirates e kubeletctl rendilo banale.
I cluster con autorizzazioni di lettura con caratteri jolly hanno esposto una media di 847 segreti Kubernetes, tra cui credenziali di database, chiavi API, certificati TLS e token IAM del provider cloud in tutti gli spazi dei nomi.
La stragrande maggioranza delle organizzazioni configura RBAC una volta durante il provisioning del cluster e non lo rivede mai più. I vincoli ai ruoli si accumulano nel corso dei mesi man mano che i team aggiungono autorizzazioni per il debug, le pipeline CI/CD e il monitoraggio, senza mai rimuoverli.
Il modulo di sicurezza Kubernetes di KENSAI ora include analisi RBAC automatizzata che mappa ogni account di servizio, ruolo e associazione nel tuo cluster per identificare i percorsi di escalation dei privilegi. Lo scanner genera un grafico visivo delle catene di autorizzazioni ed evidenzia il percorso più breve da qualsiasi carico di lavoro compromesso all'amministratore del cluster.
Ogni carico di lavoro deve avere il proprio account di servizio dedicato con solo i permessi effettivamente necessari. Evitare di associare ClusterRoles quando sono sufficienti i ruoli con ambito dello spazio dei nomi. Utilizzare automountServiceAccountToken: false per i pod che non necessitano dell'accesso API Kubernetes, che rappresenta la maggior parte dei carichi di lavoro delle applicazioni.
Kubernetes Pod Security Standards (PSS) nella restricted impedisce ai pod di essere eseguiti come root, di montare percorsi host o di utilizzare la modalità privilegiata. Applicali a livello di spazio dei nomi utilizzando Pod Security Admission. Ciò elimina il vettore di escape del contenitore anche se le autorizzazioni RBAC sono eccessivamente ampie.
Implementare audit trimestrali RBAC. Esaminare tutti i ClusterRoleBinding, identificare le associazioni obsolete dei membri del team partiti o dei servizi disattivati e verificare che nessun account di servizio disponga di autorizzazioni più ampie di quelle richieste. KENSAI può automatizzare questa operazione con il rilevamento continuo della deriva.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false su tutti i carichi di lavoro che non richiedono l'accesso APIrestricted PSS a livello di spazio dei nomi per tutti i carichi di lavoro di produzionekubectl get clusterrolebindings -o wide — contrassegna tutto ciò che è legato a gruppi ampikensai scan --k8s-rbac rispetto al tuo cluster per ottenere una valutazione completa del rischio RBAC in meno di 60 secondi. Il rapporto include un grafico di escalation dei privilegi, passaggi di risoluzione specifici per ogni risultato e mappatura della conformità NIS2 per le organizzazioni soggette alla direttiva.
*) dai ClusterRoles personalizzatisystem:authenticated o system:serviceaccountsautomountServiceAccountToken: false su tutti i pod che non necessitano dell'accesso APIrestricted livello per gli spazi dei nomi di produzione