2 November 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Kubernetes penetration testing: what is in scope, what we find and how to prepare your clusters
A Kubernetes cluster is a small data center with its own identity system, network, storage and software supply chain. A cloud configuration review or an image scan covers only a slice of it. This guide explains what a Kubernetes penetration test examines, the control gaps that recur across EKS, AKS, GKE and self-managed clusters, which frameworks apply, and what your platform team should have ready before testers start.
What Kubernetes penetration testing is, and why a cluster needs its own test
Kubernetes penetration testing is a manual, scoped security test of a Kubernetes environment: the control plane and its API, the identity and authorization model (RBAC, service accounts, cloud identity mappings), secrets handling, the network model inside and around the cluster, admission control and workload isolation, the container images and the pipeline that builds them, and the boundary between what the cloud provider manages and what your team manages. Testers combine the perspective of an external attacker, an authenticated user with limited rights, and an attacker who already holds a foothold inside one workload, then report how far each position could get and which controls stopped them or should have.
A cluster needs its own test because the common tooling leaves gaps between layers. A cloud posture scan sees the managed service settings but not what happens inside the cluster. An image scanner sees known vulnerabilities in packages but not whether a vulnerable container can reach the API server with a service account that can read every secret in the namespace. A CIS Benchmark audit confirms configuration flags but cannot tell you whether three medium-rated settings together form a path from a public web pod to cluster administrator. Penetration testing follows those chains to their end and tells you which link to cut first.
What is in scope: the nine layers of a Kubernetes penetration test
A complete cluster test covers these layers and the seams between them. Your scope statement should name each one, including the ones you exclude.
Control plane and API server
How the Kubernetes API is exposed and to whom, whether encryption in transit and at rest for control-plane data is enabled, and how authentication is delegated to your identity provider or cloud IAM. On managed services the exposure and access configuration remain yours.
Authentication, RBAC and service accounts
Roles and cluster roles mapped to the human and machine identities that hold them, how service account tokens reach pods, and permissions that let a low-value workload read secrets, create workloads or escalate across namespaces. Most cluster findings live here.
Secrets and configuration
How credentials and keys reach workloads: Secret objects, external stores, environment variables, mounted files. The test checks encryption at rest, who can read secrets through the API, leakage into logs, images or repositories, and whether rotation is possible.
Network model, ingress and egress
Kubernetes networking is flat by default: every pod can reach every other pod unless a network policy says otherwise. Testers check segmentation between namespaces and tiers, exposure of ingress controllers, outbound access to the internet and cloud metadata services, and whether policy is actually enforced.
Admission control and workload isolation
Pod Security Standards (Privileged, Baseline, Restricted) and the admission controllers or policy engines that enforce them. The test checks whether privileged containers, host namespaces, host path mounts and root execution are blocked where they should be, and whether exceptions are documented and time-bound.
Workloads and container images
Base images and their age, known vulnerabilities and whether they are reachable, build-time secrets left in layers, debugging tools shipped to production, and runtime settings such as read-only file systems and dropped capabilities. Image findings are weighted by exposure, not scanner count.
Software supply chain and registries
CI pipelines, registry access controls, image signing and verification, Helm charts and third-party manifests, GitOps controllers and the credentials they hold. A pipeline with write access to the cluster is a privileged identity and is tested as one.
Managed-service shared responsibility (EKS, AKS, GKE)
The provider secures control-plane hardware and software; you secure node configuration, identity mappings to cloud IAM, network exposure, workloads and add-ons. The report records which side each finding sits on, which decides remediation ownership and satisfies auditors.
Audit logging and detection
Whether Kubernetes audit logging is enabled at a useful level, shipped to a SIEM or managed detection service, and retained for PCI DSS Requirement 10 or SOC 2 CC7.2. Where agreed, testers note which of their actions produced alerts and which went unnoticed.
The control gaps we report most often
The finding classes that recur across cluster engagements, described as control gaps with the remediation direction. Severity in a real report depends on reachability and on what the gap connects to.
1. Over-privileged service accounts and RBAC bindings
Workloads bound to cluster-admin or broad wildcard roles, default tokens mounted into pods that never call the API, and cluster-wide bindings where a namespace role would do. Fix: least privilege per workload, token mounting disabled where unused, RBAC review inside change management.
2. Missing or incomplete network policies
Namespaces without a default-deny policy, policies that cover ingress but not egress, and pods able to reach metadata endpoints, databases or management interfaces they have no business reaching. Fix: a default-deny baseline per namespace with explicit allow rules, enforced by a policy engine and validated in CI.
3. Privileged and permissive workloads
Containers running as root with host namespaces, host path mounts or added capabilities, often inherited from a vendor chart that was never revisited. Fix: enforce the Restricted or Baseline Pod Security Standard by namespace, with documented exceptions that expire.
4. Cluster components reachable from where they should not be
Dashboards, metrics endpoints, API servers and node ports exposed to the internet or the whole corporate network, and workloads that can reach the cloud instance metadata service and inherit the node's cloud role. Fix: private API endpoints, authenticated and network-restricted dashboards, metadata access blocked or scoped to workload identity.
5. Stale images and an unverified supply chain
Base images many releases behind, images pulled by mutable tag rather than digest, no signature verification at admission, registries writable by too many identities. Fix: a rebuild cadence tied to vulnerability intelligence, pinned and signed images verified at admission, registry permissions treated as production credentials.
6. Secrets handled as ordinary configuration
Credentials in environment variables visible to anyone who can describe a pod, secrets committed to manifests, no encryption at rest for control-plane data, long-lived tokens never rotated. Fix: an external secret store with short-lived identity-based access, and encryption at rest enabled.
Cluster scanning versus Kubernetes penetration testing
Each has a place in a container security program. They answer different questions, and only one answers the question your board asks: could someone get in, and how far.
| Aspect | Image scanning | Posture / benchmark audit (KSPM, CIS) | Kubernetes penetration test |
|---|---|---|---|
| Question answered | Which known vulnerabilities are in our images? | Which settings deviate from the benchmark? | Can an attacker move from an exposed workload to cluster or cloud control, and which control stops them? |
| Method | Automated package matching | Automated checks against CIS and provider baselines | Manual testing from external, authenticated and assumed-breach positions |
| Covers the seams between layers | No | Partly, one layer at a time | Yes, that is the point |
| Context for severity | CVSS of the package | Benchmark level | Reachability, chained impact, business function behind the workload |
| Frequency | Every build | Continuous or weekly | Annually and after major platform changes |
| Compliance role | 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 |
| Output | Vulnerability list per image | Pass/fail per control | Attack narrative, CVSS-scored findings with evidence, prioritized remediation, retest |
How a Kubernetes penetration test runs
A typical engagement for one production cluster and its build pipeline takes one to two weeks of testing, depending on cluster size and the positions agreed.
1. Scoping and the shared-responsibility map
We list clusters, namespaces, environments, ingress points, registries and pipelines in scope, agree exclusions, and record for each component whether the provider or your team is responsible. This also decides whether node-level testing applies (usually yes for self-managed node groups, usually no for serverless node models).
2. Test positions and access
Most cluster tests combine three positions: external, authenticated developer or operator, and assumed breach from inside a low-privilege workload. Grey-box access with read rights to manifests and architecture documentation yields more findings per day than black-box discovery; our explainer on black-, grey- and white-box testing covers the trade-off.
3. Control plane, identity and secrets review
API exposure, authentication delegation, RBAC bindings per identity, service account token handling, and how secrets are stored and read. The output is a privilege map: which identity can reach what, and where a single compromise would expand.
4. Workload, network and admission review
From the assumed-breach position testers establish what a compromised pod can reach, what it is allowed to be, and whether admission control would have blocked a hostile deployment. Network policy is validated by observation, not by reading manifests.
5. Supply chain and cloud boundary review
Registry permissions, image provenance, pipeline credentials and GitOps controllers are tested as identities, and testers check whether cluster identities can reach cloud resources beyond the cluster. This is where the Kubernetes engagement connects to the broader cloud penetration test.
6. Reporting, remediation workshop and retest
Executive summary, attack narrative per position, CVSS-scored findings with evidence and the responsible side of the shared-responsibility line, and a prioritized remediation plan. A walkthrough with the platform team follows, and medium or higher findings are retested within 90 days.
Frameworks and compliance mapping
Three public references define what good looks like, and a report should cite them. The CIS Kubernetes Benchmark, with provider companions for EKS, AKS and GKE, sets configuration baselines for control plane, nodes, policies and managed services. The NSA and CISA Kubernetes Hardening Guide (version 1.2, August 2022) organizes recommendations around pod security, network separation, authentication and authorization, audit logging and upgrades, which is also a sensible structure for a scope statement. NIST SP 800-190, the Application Container Security Guide, frames the risk across images, registries, orchestrators, containers and hosts, and is the reference US auditors recognize most readily.
On the compliance side, PCI DSS v4.0.1 brings containerized services into scope wherever they store, process or transmit cardholder data or can affect its security: Requirement 11.4 (penetration testing), 6.3 (vulnerability management), 2.2 (configuration standards) and 10 (logging) all apply to the cluster. SOC 2 examinations map cluster testing to CC4.1, CC6.1, CC6.6 and CC7.1. The HIPAA Security Rule risk analysis at 45 CFR 164.308(a)(1)(ii)(A) expects covered entities to evaluate the platforms that process electronic protected health information. FedRAMP control CA-8 and CMMC 2.0 Level 2 practice CA.L2-3.12.1 require periodic penetration testing of the in-scope environment. For EU operations the same test serves NIS2 Article 21(2)(f), DORA Article 25 and ISO 27001:2022 controls A.8.8 and A.8.9. One well-scoped cluster test covers all of these if the scope statement maps the cluster to each framework.
What to prepare before the test
Preparation shortens discovery and puts the testing days where they matter. Have these ready at kickoff.
- An inventory of clusters, environments and namespaces in scope, with the business function behind each production namespace
- Architecture documentation: how traffic enters, how workloads talk to each other, which cloud services the cluster depends on
- The shared-responsibility position for each managed service, and whether node groups are self-managed or serverless
- Read access to manifests, Helm charts and policy definitions for grey-box testing, or a clear decision to test black box
- Test identities per agreed position: a developer-level account and a low-privilege workload or namespace to start from
- A named platform owner, an escalation path for critical findings, and agreed testing windows for anything that could affect availability
- Confirmation of what must not be touched: production data stores, shared tenants, third-party systems outside your authorization
How HackersHub tests Kubernetes
Kubernetes testing at HackersHub is delivered within our cloud penetration testing practice, because a cluster never stands alone: its identities map to cloud IAM, its secrets live in cloud key stores and its nodes run on cloud compute. Our testers hold at least OSCP, with OSWE and CREST-certified testers on the team, and the methodology aligns with PTES and NIST SP 800-115, extended with the CIS Kubernetes Benchmark, the NSA and CISA hardening guide and NIST SP 800-190.
Every report names the lead tester and includes an executive summary, an attack narrative per test position, CVSS-scored findings with evidence and the shared-responsibility owner for each, and a prioritized remediation plan. A verification retest of medium and higher findings within 90 days is included. We deliver remotely from Amsterdam, Netherlands, for US and EU clients, with on-site work where an engagement requires it, and every engagement is scoped individually.
Frequently asked questions
Related guides and services
- Cloud penetration testing by HackersHub
- Active Directory penetration testing: scope, control gaps and remediation priorities
- Black box vs grey box vs white box penetration testing
- Penetration testing methodology: standards, phases and evidence
- Red team vs penetration testing: which one your cluster needs
- Penetration test vs vulnerability scan
- PCI DSS penetration testing: Requirement 11.4 explained
- Penetration testing services by HackersHub
Running production on Kubernetes?
We test the cluster, the pipeline and the cloud boundary as one system, and report each finding with its shared-responsibility owner and a remediation priority your platform team can act on. Talk to an expert.