2 november 2026 · 10 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Kubernetes pentest: wat in scope is, wat wij aantreffen en hoe u uw clusters voorbereidt
Een Kubernetes-cluster is een klein datacenter met een eigen identiteitsmodel, netwerk, opslag en softwaretoeleveringsketen. Een cloudconfiguratiereview of een image-scan dekt daar maar een deel van. Deze gids legt uit wat een Kubernetes pentest onderzoekt, welke hiaten steeds terugkomen op EKS, AKS, GKE en zelfbeheerde clusters, welke kaders gelden en wat uw platformteam gereed moet hebben voordat de testers beginnen.
Wat een Kubernetes pentest is, en waarom een cluster een eigen test nodig heeft
Een Kubernetes pentest is een handmatige, afgebakende beveiligingstest van een Kubernetes-omgeving: het control plane en de API, het identiteits- en autorisatiemodel (RBAC, service accounts, koppelingen met cloudidentiteiten), de omgang met secrets, het netwerkmodel binnen en rond het cluster, admission control en isolatie van workloads, de container-images en de pipeline die ze bouwt, en de grens tussen wat de cloudaanbieder beheert en wat uw team beheert. Testers combineren het perspectief van een externe aanvaller, een geauthenticeerde gebruiker met beperkte rechten en een aanvaller die al voet aan de grond heeft in één workload, en rapporteren hoe ver elke positie kwam en welke maatregelen dat tegenhielden of hadden moeten tegenhouden.
Een cluster heeft een eigen test nodig omdat de gangbare tooling hiaten laat tussen de lagen. Een cloud posture scan ziet de instellingen van de beheerde dienst, maar niet wat er binnen het cluster gebeurt. Een image-scanner ziet bekende kwetsbaarheden in pakketten, maar niet of een kwetsbare container de API-server kan bereiken met een service account dat elk secret in de namespace kan lezen. Een CIS Benchmark-audit bevestigt configuratievlaggen, maar kan u niet vertellen of drie middelzware instellingen samen een pad vormen van een publieke webpod naar clusterbeheerder. Penetratietesten volgt zulke ketens tot het einde en geeft aan welke schakel u als eerste doorknipt.
Wat in scope is: de negen lagen van een Kubernetes pentest
Een volledige clustertest dekt deze lagen en de naden ertussen. Uw scopeverklaring benoemt elke laag, ook de lagen die u uitsluit.
Control plane en API-server
Hoe de Kubernetes-API is ontsloten en voor wie, of versleuteling onderweg en in rust voor control-plane-data is ingeschakeld, en hoe authenticatie is gedelegeerd aan uw identity provider of cloud-IAM. Bij beheerde diensten blijven ontsluiting en toegangsconfiguratie van u.
Authenticatie, RBAC en service accounts
Roles en cluster roles per menselijke en machine-identiteit, hoe service-account-tokens pods bereiken, en rechten waarmee een laagwaardige workload secrets kan lezen, workloads kan aanmaken of over namespaces heen kan escaleren. Hier zitten de meeste clusterbevindingen.
Secrets en configuratie
Hoe inloggegevens en sleutels de workloads bereiken: Secret-objecten, externe stores, omgevingsvariabelen, gemounte bestanden. De test controleert versleuteling in rust, wie secrets via de API kan lezen, weglekken in logs, images of repositories, en of rotatie mogelijk is.
Netwerkmodel, ingress en egress
Kubernetes-netwerken is standaard plat: elke pod bereikt elke andere pod tenzij een network policy anders bepaalt. Testers controleren segmentatie tussen namespaces en lagen, ontsluiting van ingress controllers, uitgaande toegang naar internet en cloudmetadatadiensten, en of beleid daadwerkelijk wordt afgedwongen.
Admission control en workload-isolatie
De Pod Security Standards (Privileged, Baseline, Restricted) en de admission controllers of policy engines die ze afdwingen. De test controleert of privileged containers, host-namespaces, host-path-mounts en uitvoering als root worden geblokkeerd waar dat hoort, en of uitzonderingen gedocumenteerd en tijdgebonden zijn.
Workloads en container-images
Basis-images en hun leeftijd, bekende kwetsbaarheden en of ze bereikbaar zijn, build-secrets in lagen, debugtools die mee naar productie gaan, en runtime-instellingen zoals read-only bestandssystemen en afgestoten capabilities. Image-bevindingen worden gewogen op blootstelling, niet op scanneraantal.
Softwaretoeleveringsketen en registries
CI-pipelines, toegangsbeheer op registries, image-ondertekening en -verificatie, Helm charts en manifests van derden, GitOps-controllers en de credentials die zij bezitten. Een pipeline met schrijfrechten op het cluster is een bevoorrechte identiteit en wordt als zodanig getest.
Gedeelde verantwoordelijkheid bij EKS, AKS en GKE
De aanbieder beveiligt hardware en software van het control plane; u beveiligt node-configuratie, identiteitskoppelingen naar cloud-IAM, netwerkontsluiting, workloads en add-ons. Het rapport legt vast aan welke kant elke bevinding valt, wat het eigenaarschap van herstel bepaalt en auditors overtuigt.
Auditlogging en detectie
Of Kubernetes-auditlogging op een zinvol niveau staat, naar een SIEM of managed-detectiedienst gaat en lang genoeg wordt bewaard voor PCI DSS Requirement 10 of SOC 2 CC7.2. Waar afgesproken noteren testers welke van hun handelingen alarmen gaven en welke onopgemerkt bleven.
De hiaten die wij het vaakst rapporteren
De bevindingsklassen die in clusteropdrachten steeds terugkomen, beschreven als hiaten in beheersmaatregelen met de herstelrichting. De ernst in een echt rapport hangt af van bereikbaarheid en van wat het hiaat verbindt.
1. Te ruime service accounts en RBAC-bindings
Workloads gekoppeld aan cluster-admin of brede wildcard-rollen, standaardtokens gemount in pods die de API nooit aanroepen, en clusterbrede bindings waar een namespace-rol had volstaan. Herstel: least privilege per workload, token-mounting uit waar ongebruikt, RBAC-review binnen wijzigingsbeheer.
2. Ontbrekende of onvolledige network policies
Namespaces zonder default-deny-beleid, policies die ingress wel maar egress niet dekken, en pods die metadata-endpoints, databases of beheerinterfaces bereiken waar zij niets te zoeken hebben. Herstel: een default-deny-basis per namespace met expliciete allow-regels, afgedwongen door een policy engine en gevalideerd in CI.
3. Privileged en te ruim geconfigureerde workloads
Containers die als root draaien met host-namespaces, host-path-mounts of extra capabilities, vaak geërfd van een leverancierschart die nooit is herzien. Herstel: de Restricted of Baseline Pod Security Standard per namespace afdwingen, met gedocumenteerde uitzonderingen die verlopen.
4. Clustercomponenten bereikbaar vanaf plekken waar dat niet hoort
Dashboards, metrics-endpoints, API-servers en node ports die openstaan naar internet of het hele bedrijfsnetwerk, en workloads die de instance-metadatadienst bereiken en zo de cloudrol van de node erven. Herstel: private API-endpoints, geauthenticeerde en netwerkmatig afgeschermde dashboards, metadatatoegang geblokkeerd of beperkt tot workload-identiteit.
5. Verouderde images en een ongeverifieerde toeleveringsketen
Basis-images die vele releases achterlopen, images opgehaald op een veranderlijke tag in plaats van een digest, geen handtekeningverificatie bij admission, registries waar te veel identiteiten naar schrijven. Herstel: een herbouwcadans gekoppeld aan kwetsbaarheidsinformatie, vastgepinde en ondertekende images geverifieerd bij admission, registry-rechten behandeld als productiecredentials.
6. Secrets behandeld als gewone configuratie
Credentials in omgevingsvariabelen die zichtbaar zijn voor iedereen die een pod kan beschrijven, secrets in manifests in versiebeheer, geen versleuteling in rust voor control-plane-data, langlevende tokens die nooit roteren. Herstel: een externe secret store met kortlevende, identiteitsgebaseerde toegang, en versleuteling in rust ingeschakeld.
Clusterscanning versus Kubernetes pentest
Elk heeft een plaats in een containerbeveiligingsprogramma. Ze beantwoorden verschillende vragen, en maar één beantwoordt de vraag die uw bestuur stelt: kan iemand binnenkomen, en hoe ver.
| Aspect | Image-scanning | Posture- / benchmark-audit (KSPM, CIS) | Kubernetes pentest |
|---|---|---|---|
| Beantwoorde vraag | Welke bekende kwetsbaarheden zitten in onze images? | Welke instellingen wijken af van de benchmark? | Kan een aanvaller van een blootgestelde workload naar cluster- of cloudcontrole komen, en welke maatregel houdt dat tegen? |
| Methode | Geautomatiseerde pakketmatching | Geautomatiseerde controles tegen CIS en aanbiedersbaselines | Handmatig testen vanuit externe, geauthenticeerde en assumed-breach-posities |
| Dekt de naden tussen lagen | Nee | Deels, één laag tegelijk | Ja, dat is de kern |
| Context voor ernst | CVSS van het pakket | Benchmarkniveau | Bereikbaarheid, geketende impact, bedrijfsfunctie achter de workload |
| Frequentie | Elke build | Continu of wekelijks | Jaarlijks en na grote platformwijzigingen |
| Rol in compliance | PCI DSS 6.3, SOC 2 CC7.1 | PCI DSS 2.2, ISO 27001 A.8.9 | PCI DSS 11.4, SOC 2 CC4.1, NIS2 art. 21(2)(f), DORA art. 25 |
| Resultaat | Kwetsbaarheidslijst per image | Geslaagd/gefaald per maatregel | Aanvalsverhaal, CVSS-gescoorde bevindingen met bewijs, geprioriteerd herstel, hertest |
Hoe een Kubernetes pentest verloopt
Een gebruikelijke opdracht voor één productiecluster en de bouwpipeline vergt een tot twee weken testwerk, afhankelijk van clusteromvang en de afgesproken posities.
1. Scoping en de verantwoordelijkheidskaart
Wij inventariseren clusters, namespaces, omgevingen, ingress-punten, registries en pipelines in scope, spreken uitsluitingen af en leggen per component vast of de aanbieder of uw team verantwoordelijk is. Dit bepaalt ook of node-testen van toepassing is (meestal wel bij zelfbeheerde node groups, meestal niet bij serverless node-modellen).
2. Testposities en toegang
De meeste clustertests combineren drie posities: extern, geauthenticeerde ontwikkelaar of beheerder, en assumed breach vanuit een workload met weinig rechten. Grey-box-toegang met leesrechten op manifests en architectuurdocumentatie levert meer bevindingen per dag dan black-box-discovery; onze uitleg over black-, grey- en white-box-testen behandelt die afweging.
3. Review van control plane, identiteit en secrets
API-ontsluiting, delegatie van authenticatie, RBAC-bindings per identiteit, omgang met service-account-tokens en hoe secrets worden opgeslagen en gelezen. Het resultaat is een rechtenkaart: welke identiteit wat kan bereiken, en waar één compromittering zich zou uitbreiden.
4. Review van workloads, netwerk en admission
Vanuit de assumed-breach-positie stellen testers vast wat een gecompromitteerde pod kan bereiken, wat hij mag zijn en of admission control een vijandige deployment had geblokkeerd. Network policy wordt gevalideerd door waarneming, niet door manifests te lezen.
5. Review van toeleveringsketen en cloudgrens
Registry-rechten, image-herkomst, pipeline-credentials en GitOps-controllers worden als identiteiten getest, en testers controleren of clusteridentiteiten cloudresources buiten het cluster bereiken. Hier sluit de Kubernetes-opdracht aan op de bredere cloud pentest.
6. Rapportage, herstelworkshop en hertest
Managementsamenvatting, aanvalsverhaal per positie, CVSS-gescoorde bevindingen met bewijs en de verantwoordelijke kant van de verantwoordelijkheidslijn, en een geprioriteerd herstelplan. Een doorloop met het platformteam volgt, en bevindingen van middelzwaar of hoger worden binnen 90 dagen hertest.
Kaders en compliance-mapping
Drie publieke referenties bepalen wat goed is, en een rapport hoort ze te citeren. De CIS Kubernetes Benchmark, met aanbiedersvarianten voor EKS, AKS en GKE, stelt configuratiebaselines voor control plane, nodes, policies en beheerde diensten. De Kubernetes Hardening Guide van NSA en CISA (versie 1.2, augustus 2022) ordent aanbevelingen rond podbeveiliging, netwerkscheiding, authenticatie en autorisatie, auditlogging en upgrades, wat ook een verstandige structuur is voor een scopeverklaring. NIST SP 800-190, de Application Container Security Guide, kadert het risico over images, registries, orchestrators, containers en hosts en is de referentie die Amerikaanse auditors het best kennen.
Aan de compliancekant brengt PCI DSS v4.0.1 gecontaineriseerde diensten in scope zodra zij kaarthoudergegevens opslaan, verwerken of doorgeven of de beveiliging daarvan kunnen beïnvloeden: Requirement 11.4 (penetratietesten), 6.3 (kwetsbaarheidsbeheer), 2.2 (configuratiestandaarden) en 10 (logging) gelden alle voor het cluster. SOC 2-onderzoeken koppelen clustertesten aan CC4.1, CC6.1, CC6.6 en CC7.1. De risicoanalyse uit de HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), verwacht dat organisaties de platformen beoordelen die beschermde gezondheidsgegevens verwerken. FedRAMP-maatregel CA-8 en CMMC 2.0 Level 2 practice CA.L2-3.12.1 vereisen periodieke penetratietesten van de omgeving in scope. Voor activiteiten in de EU dient dezelfde test NIS2 artikel 21(2)(f), DORA artikel 25 en ISO 27001:2022-maatregelen A.8.8 en A.8.9. Eén goed gescopete clustertest dekt al deze kaders als de scopeverklaring het cluster aan elk kader koppelt.
Wat u voorbereidt vóór de test
Voorbereiding verkort de discovery en zet de testdagen in waar ze tellen. Houd dit gereed bij de kick-off.
- Een inventaris van clusters, omgevingen en namespaces in scope, met de bedrijfsfunctie achter elke productienamespace
- Architectuurdocumentatie: hoe verkeer binnenkomt, hoe workloads met elkaar praten, van welke clouddiensten het cluster afhangt
- De verantwoordelijkheidsverdeling per beheerde dienst, en of node groups zelfbeheerd of serverless zijn
- Leesrechten op manifests, Helm charts en policydefinities voor grey-box-testen, of een duidelijk besluit om black box te testen
- Testidentiteiten per afgesproken positie: een account op ontwikkelaarsniveau en een workload of namespace met weinig rechten als startpunt
- Een platformeigenaar bij naam, een escalatiepad voor kritieke bevindingen en afgesproken testvensters voor alles wat de beschikbaarheid kan raken
- Bevestiging van wat niet aangeraakt mag worden: productiedatabases, gedeelde tenants, systemen van derden buiten uw mandaat
Hoe HackersHub Kubernetes test
Kubernetes-testen bij HackersHub is onderdeel van onze cloud pentest-praktijk, omdat een cluster nooit op zichzelf staat: zijn identiteiten koppelen aan cloud-IAM, zijn secrets staan in cloudsleutelbeheer en zijn nodes draaien op cloudrekenkracht. Onze testers hebben minimaal OSCP, met OSWE- en CREST-gecertificeerde testers in het team, en de methodiek sluit aan op PTES en NIST SP 800-115, aangevuld met de CIS Kubernetes Benchmark, de hardening guide van NSA en CISA en NIST SP 800-190.
Elk rapport noemt de lead tester bij naam en bevat een managementsamenvatting, een aanvalsverhaal per testpositie, CVSS-gescoorde bevindingen met bewijs en de verantwoordelijke partij per bevinding, en een geprioriteerd herstelplan. Een verificatiehertest van middelzware en hogere bevindingen binnen 90 dagen is inbegrepen. Wij leveren op afstand vanuit Amsterdam voor klanten in de EU en de VS, met werk op locatie waar een opdracht dat vraagt, en elke opdracht wordt afzonderlijk gescopet.
Veelgestelde vragen
Gerelateerde gidsen en diensten
- Cloud pentest door HackersHub
- Penetratietest laten uitvoeren door HackersHub
- Active Directory pentest: scope, hiaten en herstelprioriteiten
- Black box, grey box en white box pentest vergeleken
- Pentest methodiek: standaarden, fasen en bewijs
- Red teaming vs pentest: wat uw cluster nodig heeft
- Penetratietest vs kwetsbaarheidsscan
- PCI DSS pentest: Requirement 11.4 uitgelegd
Draait uw productie op Kubernetes?
Wij testen het cluster, de pipeline en de cloudgrens als één systeem en rapporteren elke bevinding met de verantwoordelijke partij en een herstelprioriteit waar uw platformteam mee aan de slag kan. Praat met een expert.