Kubernetes Penetration Testing: Beyond the Benchmark Scan

Kubernetes penetration testing is a manual assessment. A tester tries to break into and move around your cluster the way a real attacker would. Most businesses that run Kubernetes still don’t commission one. They run a CIS Benchmark scan and see a wall of green passes. They treat that as proof the cluster is secure. It isn’t. A benchmark scan checks configuration against a checklist. It cannot tell you whether two individually passing settings combine into a working attack path. In Kubernetes, they very often do.

That gap between “the scan passed” and “the cluster is actually secure” is where real incidents happen. It’s worth being blunt about this. A lot of the marketing around cloud security tooling implies that automated scanning is enough on its own. It isn’t. The difference matters most for businesses that assume a managed Kubernetes platform has already taken care of it. That includes EKS, AKS and GKE.

Why a passing scan doesn’t mean a secure cluster

Automated tools like kube-bench check your cluster’s configuration against the CIS Kubernetes Benchmark, a well-respected set of hardening rules published by the Center for Internet Security. That’s genuinely useful. But a benchmark check looks at settings in isolation. It can confirm that a service account isn’t using an overly broad cluster role by name. It will still miss the case where that same account is combined with a slightly too-permissive role binding elsewhere. Together, they let a compromised pod read every secret in the namespace.

Chained weaknesses like that are exactly what Kubernetes penetration testing is built to find. A tester doesn’t just read configuration, they act on it. That means gaining a foothold in a container, then trying to escalate privilege, read secrets, or reach across namespace boundaries. It’s exactly what an intruder would do after a web application compromise or a poisoned image in the supply chain.

A case study in what “secure enough” actually looks like

The clearest illustration is still Tesla’s 2018 breach. According to CNBC’s coverage at the time, attackers found a Kubernetes administration console that had been left without a password. They used it to reach credentials for Tesla’s AWS environment, then ran cryptocurrency mining software inside the company’s cloud infrastructure for weeks. An unauthenticated console failing quietly would not necessarily show up on a routine uptime check. It’s the kind of gap that a determined, curious human, whether attacker or tester, finds far faster than an automated tool built to check known settings.

What Kubernetes penetration testing actually covers

Kubernetes penetration testing works through the cluster in layers, since access at one level frequently opens the next:

• Control plane: the API server, etcd and scheduler, where cluster-wide authority lives.
• RBAC and service accounts: the single most common source of privilege escalation findings in real engagements.
• Workloads: pod and container configuration, including what secrets a compromised container can reach.
• Network: whether namespace boundaries and network policies actually stop lateral movement, or only look like they do.

Testers work to published methodology rather than guesswork. The OWASP Kubernetes Security Testing Guide structures the assessment process. The MITRE ATT&CK matrix for containers catalogues the real techniques attackers use against orchestration platforms. Findings get measured against the CIS Benchmark and the broader hardening guidance in NIST SP 800-190, so the results are grounded in recognised standards rather than one tester’s opinion.

“We’re on a managed cloud platform, so we’re covered”

This is the assumption that causes the most damage, because it’s half right. AWS, Google and Microsoft do secure the control plane infrastructure behind their managed Kubernetes services. That’s a genuine chunk of risk removed. But under the shared responsibility model every provider publishes, the RBAC roles you create, the network policies you do or don’t write, the secrets your workloads reach, and the third-party Helm charts your team installs are entirely yours to secure. The provider’s security work stops well before your applications start. That’s the same gap we see across wider cloud penetration testing engagements, not just inside Kubernetes.

None of this means benchmark scanning and automated tooling are a waste of time. Run them continuously, since they catch drift and obvious misconfiguration cheaply and immediately. But treat a clean scan as a floor, not a ceiling. It tells you the cluster meets a baseline. It doesn’t tell you whether that baseline holds up against someone actively trying to break it, which is the whole point of Kubernetes penetration testing.

The findings that keep repeating

Look across enough Kubernetes engagements and the same weaknesses come up again and again. That alone is a sign that scanning isn’t catching them. Containers still get deployed as privileged when they don’t need to be, which can hand a tester, or an attacker, a direct route to the underlying host. Default service accounts still carry broader RBAC rights than the workload actually uses. Namespaces still rely on Kubernetes’ default behaviour, which allows any pod to talk to any other pod unless someone has explicitly written a network policy to stop it. Administration interfaces still get exposed without authentication, exactly as happened at Tesla.

Every one of those is the kind of thing a CIS Benchmark scan can miss. Each setting can look individually acceptable while the combination isn’t. That’s the pattern worth remembering: the risk lives in the combination, not the individual line item.

How often you need to revisit it

Kubernetes clusters change constantly: new services, new Helm charts, new team access. An annual test is a sensible baseline for a stable environment. Any significant change is a reason to test again rather than wait for the calendar: a new team onboarding, a new externally exposed service, a shift in how secrets are managed. Businesses that treat testing as a one-off box-tick are usually the ones still carrying the same RBAC misconfiguration long after it was first introduced, because nothing short of another test would have caught it.

What to expect from the report

A report worth commissioning shows the actual steps taken to reach each finding, not just a severity label copied from a scanner. It should rate impact in terms your business understands: what an attacker could actually reach or do. It should give your platform team fixes they can implement without a translation exercise. If a report reads like a rebranded scan output, the engagement probably was one.

Aardwolf Security scopes Kubernetes penetration testing and wider container assessments around how your cluster is genuinely built, chained findings included, rather than handing back a benchmark printout with a cover page. This can run alongside a broader penetration testing engagement covering the applications the cluster hosts. If you’ve only ever run automated scans against your cluster, it’s worth a conversation about what a manual test would add. Get in touch and we’ll talk through scope honestly.

Frequently asked questions

Isn’t a CIS Benchmark scan enough on its own?

It’s a good baseline, but it checks configuration in isolation. It won’t catch chained weaknesses where two passing settings combine into an exploitable path. That’s exactly what manual testing is designed to find.

Does a managed Kubernetes service remove the need for testing?

No. The cloud provider secures the control plane infrastructure. RBAC, network policies, secrets and workload configuration remain your responsibility under the shared responsibility model, and those are exactly what gets tested.

How is Kubernetes penetration testing different from a general cloud security review?

A cloud security review typically checks account-level settings such as IAM policies and storage permissions. Kubernetes penetration testing goes inside the cluster to test RBAC, workloads and network paths directly. Many organisations need both.

What’s a reasonable frequency for testing?

Annually as a baseline, with an additional test after any significant change, such as a new team, a new externally facing service, or a change in how secrets are managed.