Kubernetes Penetration Testing: What a Real Test Covers, and Why a Config Scan Isn’t One

What Kubernetes penetration testing actually covers

Ask a platform team whether their cluster is secure and you will usually get a benchmark score. Ask an attacker the same question and they will ask a different one: what can I reach from here?

Kubernetes penetration testing is the discipline of answering the attacker’s question, with proof, inside an agreed scope. It starts from a realistic position — a compromised application container, a leaked kubeconfig, a developer account, or simply the cluster’s public edge — and works out how far that position can be turned into something that matters.

That framing is the whole difference between a test and an audit. An audit checks whether each setting matches a recommended value. A test checks whether the settings, taken together, actually stop someone.

Here’s the thing: a cluster can pass most of a hardening benchmark and still hand an attacker the keys. The individual settings are fine. The relationships between them are not. Kubernetes penetration testing exists to examine the relationships.

In practice a thorough engagement covers the control plane and its API, the authorisation model (roles, bindings, service accounts), workload isolation (what one pod can do to another, and to the node it runs on), secrets handling, network policy, the supply chain feeding the cluster (registries, CI pipelines, Helm charts), and the cloud identity the cluster borrows from its provider. Each is a place where a small mistake becomes a large one when combined with another.

Why clusters leak privilege rather than break

Most people picture a breach as a door kicked in. Kubernetes compromise rarely looks like that. It looks like a series of small, individually reasonable permissions that add up to something nobody intended.

Role-based access control is the usual starting point. Kubernetes lets you grant very specific verbs on very specific resources, which is powerful, and also exactly why clusters accumulate role bindings nobody remembers writing. A service account that can list secrets in one namespace. A role that can create workloads. A binding copied from a tutorial two years ago.

None of these is a vulnerability on its own. The trouble starts when the ability to create a workload meets a workload type that runs with more privilege, or when a token readable by one component is also valid somewhere more important. Privilege does not break out of a cluster. It leaks, one permission at a time, until it pools somewhere dangerous.

Service-account tokens deserve their own mention. Every pod gets an identity, and that identity is a credential. If an application is compromised, its token comes with it, and whatever that token can do, the attacker can now do. The question Kubernetes penetration testing asks is not “is this token present?” but “what does it unlock?”

This is why the discipline is about chains. The test is not hunting for one bad setting. It is hunting for the sequence that turns an ordinary foothold into cluster-wide control.

The cluster is an identity boundary now

The second reason Kubernetes penetration testing has become its own discipline is that the cluster no longer ends at the cluster.

Modern deployments wire Kubernetes identities to cloud identities. A workload gets an IAM role so it can read a bucket or write to a queue. That is convenient, and it is correct architecture. It also means that reaching a particular pod can be the same thing as reaching a particular cloud permission — and the cloud account is usually where the data lives.

The nodes matter in the same way. A container that can break out to the node it runs on inherits whatever the node can do, which often includes credentials the node uses to talk to the cloud provider. Suddenly the question is not “what can this pod see?” but “what can this machine see?”, and the answer tends to be much bigger.

Add the supply chain. Images come from registries, charts come from repositories, deployments come from pipelines with their own credentials. Each is a route into the cluster that never touches the API server’s front door. Kubernetes penetration testing that only examines the cluster from the inside misses the ways attackers arrive.

Managed control planes change the shape of this rather than removing it. On EKS, GKE or AKS the provider runs the API server for you, which takes some classic hardening items off your list. It does nothing about your role bindings, your workload identities or your pipeline credentials — and those are where Kubernetes penetration testing finds most of what it finds. Outsourcing the control plane does not outsource the chain.

The truth is, the cluster has become the junction box of the estate. Testing it in isolation is like testing a building’s locks while ignoring that the key cabinet is on the pavement.

A configuration scan is not a penetration test

This deserves to be said plainly, because the confusion costs organisations real money and real incidents.

Tools such as kube-bench, Kubescape and Trivy are good, and you should run them. kube-bench checks a cluster against the CIS Kubernetes Benchmark. Kubescape evaluates posture against several frameworks. Trivy finds known vulnerabilities and misconfigurations in images and manifests. Together they keep a cluster hygienic, and a cluster without them is in worse shape than one with them.

What they produce, though, is a list of settings and known issues. What they do not produce is proof that any of it is reachable, exploitable or chainable. A benchmark can report that anonymous access is disabled and role bindings follow least privilege, and the cluster can still be one copied-in-from-a-blog binding away from compromise — because the benchmark checks values, not consequences.

Kubernetes penetration testing starts where the scanner stops. It takes a real position, attempts to move, and either demonstrates a path or confirms that none was found within scope. The scanner tells you the doors are the right type. The test tells you whether someone can walk through.

Treat the two as layers. Scan continuously for hygiene. Test for the chain. A clean benchmark is a necessary condition for a secure cluster. It has never been a sufficient one, and the vendors who sell a scan under the name of a pentest know that.

The path matters more than the finding

If you take one idea from this page into your next engagement, take this one: a Kubernetes finding is only as serious as the path it sits on.

A permissive role binding in a namespace nobody uses, with no workloads and no secrets, is a hygiene item. The same binding in a namespace that hosts a workload with a cloud role attached is the first step of an incident. The setting is identical. The severity is not, and only a test that follows the path can tell them apart.

This is the quiet failure of list-based reporting. Fifty findings of equal apparent severity, with no indication which three combine into something real. Engineers triage by gut, fix the loud ones, and the one that mattered sits on page nine. We wrote about this pattern more generally in what manual pentests miss; in Kubernetes it is the default outcome.

Good Kubernetes penetration testing reports the chain. Foothold, step, step, impact — with each step demonstrated, not inferred. That tells the platform team exactly which link to break first, which is usually one small change rather than fifty.

The same logic applies to the retest. Fixing the loud finding is not the goal; breaking the chain is. A retest that confirms the demonstrated path no longer works is worth more than one that confirms ten unrelated settings were tidied.

It also changes the conversation with leadership. “We have forty-seven medium findings” gets a shrug. “A compromised front-end pod reaches the customer database in three steps, here is the proof” gets a budget.

What changed since your last test

Kubernetes has a property no other part of the estate quite shares: it is designed to change constantly, and it does.

Deployments roll several times a day. Namespaces appear for a feature and are never deleted. Helm charts get upgraded, bringing new defaults with them. A platform engineer adds a role binding to unblock a release at eleven at night. Tokens rotate, or do not. The ingress gets a new annotation. Autoscaling adds nodes that were not there yesterday.

Now place an annual Kubernetes penetration testing engagement against that. The report describes the cluster as it stood for two weeks in March. By June, the namespaces it examined have been replaced, the bindings it checked have multiplied, and the chart versions it tested are two releases old. The finding list is accurate. The cluster it describes is gone.

This is not a criticism of the testers. It is a cadence mismatch, and it is more severe in Kubernetes than almost anywhere else because the rate of change is the platform’s whole point. We made the general case in our piece on enterprise penetration testing; CrowdStrike’s 2026 Global Threat Report put average attacker breakout time at 29 minutes, and a cluster that changed yesterday is a cluster the last report does not cover.

The honest conclusion is that Kubernetes penetration testing only stays true if it runs continuously — retesting the chain every time the cluster moves, not every time the calendar does.

How to scope Kubernetes penetration testing

Scoping is where most Kubernetes engagements are won or lost, usually before anyone runs anything.

Start from a realistic foothold, not from nothing. The most useful tests assume what is likely: a compromised application pod, a leaked developer credential, or a CI pipeline token. Testing only from an anonymous external position tells you about your edge and nothing about your blast radius.

Include the cloud account. If workloads carry cloud identities, the cloud is in scope, because that is where a successful chain ends. A test that stops at the cluster boundary stops exactly where the interesting part begins.

Include the supply chain. Registries, chart repositories and pipeline credentials are routes into the cluster. If they are out of scope, the test is examining the castle while ignoring the drawbridge.

Decide what “impact” means for you. Reaching the control plane, reading a specific secret, touching customer data, or gaining a cloud permission — name the targets, so that a finding can be judged by whether it reaches one.

Set rules of engagement for production. Kubernetes penetration testing against a live cluster is both the most valuable and the most sensitive kind. Agree excluded actions, rate limits and change windows, and make sure whoever runs the test can prove they respect them.

Ask how findings will be proven. If the answer is a severity label pulled from a database, you are buying a scan with a different invoice. Ask to see the shape of a reported chain before you sign.

If you want a quick sense of what your cluster exposes before scoping, our free security checks guide covers the external surface a cluster tends to leak first.

Who does this well, placed fairly

A few vendors are credible here, and a fair guide names them.

Horizon3.ai NodeZero lists Kubernetes pentesting among its solutions and advertises it directly, and its depth on infrastructure and identity — nodes, cloud, Active Directory — is a genuine strength for the cluster-to-cloud part of the chain. If your concern is primarily the infrastructure layer, it belongs on the shortlist; we compared it in full in our Horizon3 alternative page.

Aikido Security offers a free Kubernetes security scan alongside its developer-facing scanning suite. That is useful hygiene at the scanner tier, and we say so in our Aikido alternative comparison. It is a scan, not a test, which is exactly the distinction this page is about.

Specialist consultancies publish strong Kubernetes methodology and do excellent human-led engagements. Their limitation is cadence: a human-led test is a snapshot, however deep.

SelfHack AI treats Kubernetes as one layer of a full-stack scope rather than a standalone product. Our agents test the cluster together with the applications running in it, the APIs they expose and the cloud identities they carry — continuously, with every finding exploit-validated. The wider ranking, written to the same rule of crediting competitors, is in our AI pentest tools overview.

How SelfHack AI runs Kubernetes penetration testing

SelfHack AI is an autonomous penetration testing platform, and Kubernetes is one of the environments it covers as part of a scope that runs from web applications and APIs through cloud — including Google Cloud — to IoT, operational technology and beyond.

It starts from the real foothold. Rather than only probing the edge, it reasons about what a compromised workload, token or pipeline could do, and tests whether that position moves.

It follows the chain across layers. From a role binding to a workload, from a workload to a node, from a node to a cloud permission — the test does not stop at the cluster boundary, because attackers do not.

Every finding is proven. Nothing arrives as a “possible” issue. The path is demonstrated, so the platform team knows which single link to break.

It runs continuously. When the cluster changes — and it changes daily — the chain is tested again, so the report describes the cluster you run now rather than the one from last spring.

The output is evidence. Scope, findings with demonstrated impact, remediation and retest, in a form auditors accept, in 16+ languages, from a European company that works naturally with EU frameworks.

If your Kubernetes penetration testing still runs once a year against a cluster that redeploys every day, talk to us about a pilot on a cluster you own.

FAQ

How is Kubernetes penetration testing different from a Kubernetes security scan?

A scan such as kube-bench, Kubescape or Trivy checks configuration and known vulnerabilities and produces a list of findings. Kubernetes penetration testing starts from a realistic foothold and attempts to move through the cluster, proving which findings actually chain into impact. You need both; only the test tells you what an attacker can really do.

How often should Kubernetes penetration testing be done?

Annual is the common compliance floor, but Kubernetes changes far faster than any other part of an estate — deployments, namespaces, charts and bindings move daily. For most production clusters, continuous testing that re-checks the chain after each change is the only cadence that keeps the report true.

Should the cloud account be in scope for a Kubernetes test?

Yes, whenever workloads carry cloud identities, which is most production clusters. A successful chain usually ends in a cloud permission rather than inside the cluster, so a test that stops at the cluster boundary stops before the part that matters.

Is it safe to run Kubernetes penetration testing against production?

It is the most valuable kind of test and it can be run safely with agreed rules of engagement: excluded actions, rate limits, change windows and authorisation from the cluster owner. Any credible provider should be able to show how it honours those rules.

What should a Kubernetes penetration testing report contain?

Chains, not just lists: the foothold, each demonstrated step, and the impact reached, with severity judged by the path rather than the individual setting. Plus defined scope, remediation guidance for the link to break first, and a retest showing the fix held — the form auditors and platform teams can both act on.

The verdict

Kubernetes penetration testing is not a longer version of a benchmark. It is a different question — not “are the settings right?” but “how far does someone get?” — and the answer lives in the chain between settings, not in any one of them.

Run the scanners; they keep the cluster hygienic. Then test the path, from a realistic foothold, through the cluster, into the cloud account behind it. And because the cluster you tested in March is gone by June, test it continuously or accept that the report is history by the time it is read.

If you would rather know what your cluster leaks today than what it leaked last year, talk to us.

Sources & methodology: risk categories follow the OWASP Kubernetes Top Ten; container and orchestration guidance references NIST SP 800-190. Attacker breakout time is from the 2026 CrowdStrike Global Threat Report. Vendor descriptions are from each company’s public website and public advertising (Google Ads Transparency Center, Finland, October 2026); this is a SelfHack comparative assessment and SelfHack AI makes no claim about any vendor beyond what it states publicly. This page is a buyer’s guide and intentionally contains no attack commands. Only test clusters you own or are authorised to test.