Kritieke Kubernetes RBAC-misconfiguraties maken volledige clusterovername mogelijk

Het cloudbeveiligingsonderzoeksteam van KENSAI analyseerde 12.000 productie-Kubernetes-clusters bij Europese bedrijven en ontdekte dat 58% RBAC-misconfiguraties (Role-Based Access Control) bevat die ernstig genoeg zijn om lateral movement en privilege-escalatie naar cluster-admin mogelijk te maken. De vijf gevaarlijkste patronen — wildcard-permissies, misbruik van standaard service-accounts, excessieve ClusterRoleBindings, namespace-ontsnapping via podcreatierechten en tokenmounting in geprivilegieerde pods — komen voor in de meerderheid van de implementaties. De meeste organisaties auditen RBAC-beleid niet na de initiële setup. ⚡ Als een aanvaller in 58% van de gescande clusters een willekeurige pod compromitteert, kan deze binnen enkele minuten escaleren naar volledige cluster-admin-toegang, uitsluitend met RBAC-misconfiguraties.

🔓 De 5 gevaarlijkste Kubernetes RBAC-patronen

#1 — Wildcard-permissies in ClusterRoles

De meest voorkomende misconfiguratie: 23% van de clusters heeft aangepaste ClusterRoles met wildcard (*)-verbs of -resources. Teams kopiëren de rol cluster-admin als uitgangspunt en vergeten deze te versmallen. Eén pod met een service-account gekoppeld aan zo'n rol heeft onbeperkte toegang tot elke resource in elke namespace — secrets, configmaps, nodes en de API-server zelf.

# Dangerous: Wildcard ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devops-tools
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]        # ← Full cluster-admin equivalent

#2 — Misbruik van standaard service-accounts

Elke Kubernetes-namespace heeft een default-service-account die automatisch in pods wordt gemount tenzij expliciet uitgeschakeld. In 41% van de clusters heeft het standaard service-account in minstens één namespace verhoogde permissies gekregen — vaak omdat een operator tijdens het debuggen snel een kubectl create rolebinding uitvoerde en dit nooit opruimde. Aanvallers die RCE verkrijgen in een willekeurige pod in die namespace erven die permissies direct.

#3 — Excessieve ClusterRoleBindings

34% van de clusters heeft meer dan 10 aangepaste ClusterRoleBindings — bindingen die permissies over alle namespaces heen verlenen. Veel koppelen brede rollen aan groepen zoals system:authenticated of system:serviceaccounts, waardoor effectief verhoogde toegang wordt verleend aan elke geauthenticeerde gebruiker of elk service-account in het cluster.

#4 — Namespace-ontsnapping via podcreatie

Gebruikers met create pods-permissie in een willekeurige namespace kunnen het hostbestandssysteem mounten, geprivilegieerde containers draaien of pods aanmaken met een willekeurig service-account in die namespace. In 29% van de clusters hebben ontwikkelaars podcreatierechten zonder handhaving van Pod Security Standards — wat triviale containerontsnapping naar de onderliggende node mogelijk maakt.

#5 — Automatisch mounten van tokens in geprivilegieerde pods

Kubernetes mount standaard service-account-tokens in pods. Gecombineerd met geprivilegieerde podspecs of hostnetwerktoegang kunnen aanvallers het token stelen en zich authenticeren bij de API-server van buiten het cluster. Slechts 12% van de gescande clusters stelt automountServiceAccountToken: false in op workloads die geen API-toegang nodig hebben.

📊 RBAC-misconfiguratie in cijfers

• 58% van de clusters heeft kritieke RBAC-problemen: meer dan de helft van de geanalyseerde productie-Kubernetes-clusters bevat minstens één RBAC-misconfiguratie die privilege-escalatie van een gecompromitteerde pod naar toegang op cluster-admin-niveau mogelijk kan maken.
• Gemiddeld 3,2 minuten naar cluster-admin: bij penetratietests tegen verkeerd geconfigureerde clusters was de gemiddelde tijd van initiële podcompromittering tot volledige cluster-admin-toegang 3,2 minuten. Geautomatiseerde tools zoals peirates en kubeletctl maken dit triviaal.
• Gemiddeld 847 secrets blootgesteld per cluster: clusters met wildcard-leespermissies stelden gemiddeld 847 Kubernetes-secrets bloot — inclusief databasecredentials, API-sleutels, TLS-certificaten en IAM-tokens van cloudproviders over alle namespaces heen.
• 78% audit RBAC nooit na de initiële setup: de overgrote meerderheid van organisaties configureert RBAC eenmalig tijdens clusterprovisioning en beoordeelt het nooit opnieuw. Role-bindings stapelen zich maandenlang op naarmate teams permissies toevoegen voor debuggen, CI/CD-pipelines en monitoring — en verwijderen deze nooit.

🛡️ Hoe u RBAC-misconfiguraties detecteert en verhelpt

Geautomatiseerde RBAC-audit met KENSAI

De Kubernetes-beveiligingsmodule van KENSAI bevat nu geautomatiseerde RBAC-analyse die elk service-account, elke rol en elke binding in uw cluster in kaart brengt om paden voor privilege-escalatie te identificeren. De scanner genereert een visuele grafiek van permissieketens en markeert het kortste pad van elke gecompromitteerde workload naar cluster-admin.

Principe van minimale rechten voor service-accounts

Elke workload moet zijn eigen toegewijde service-account hebben met alleen de permissies die het daadwerkelijk nodig heeft. Vermijd het koppelen van ClusterRoles wanneer namespace-gescopede Roles volstaan. Gebruik automountServiceAccountToken: false voor pods die geen Kubernetes-API-toegang nodig hebben — wat de meerderheid van applicatieworkloads betreft.

Handhaaf Pod Security Standards

Kubernetes Pod Security Standards (PSS) op restricted-niveau voorkomen dat pods als root draaien, hostpaden mounten of privileged mode gebruiken. Handhaaf deze op namespace-niveau met Pod Security Admission. Dit elimineert de containerontsnappingsvector zelfs als RBAC-permissies te breed zijn.

Reguliere RBAC-beoordelingen

Implementeer kwartaal-RBAC-audits. Beoordeel alle ClusterRoleBindings, identificeer verouderde bindingen van vertrokken teamleden of buiten gebruik gestelde diensten, en valideer dat geen enkel service-account bredere permissies heeft dan vereist. KENSAI kan dit automatiseren met continue drift-detectie.

Kubernetes RBAC-hardeningschecklist

Kritiek — onmiddellijk verhelpen

• Verwijder alle wildcard (*)-verbs en -resources uit aangepaste ClusterRoles
• Verwijder verhoogde bindingen van standaard service-accounts in alle namespaces
• Trek ClusterRoleBindings in die gekoppeld zijn aan system:authenticated of system:serviceaccounts

Hoog — deze week

• Creëer toegewijde service-accounts voor elke workload met minimale permissies
• Stel automountServiceAccountToken: false in op alle pods die geen API-toegang nodig hebben
• Handhaaf Pod Security Standards op restricted-niveau voor productienamespaces

Doorlopend — proces opzetten

• Plan kwartaal-RBAC-beoordelingen met geautomatiseerde drift-detectie
• Integreer RBAC-validatie in CI/CD-pipelines voor infrastructure-as-code
• Schakel Kubernetes API-auditlogs in en monitor deze op pogingen tot privilege-escalatie
• Documenteer RBAC-beleid en onderhoud een service-account-inventaris