Kubernetes does not replace your application security problems—it stacks an orchestration layer on top of them. Every cluster introduces a control plane, a node runtime, an identity model, a software-defined network, and a secrets store, each with its own failure modes. A single overpermissive RoleBinding or one privileged: true pod can turn a low-severity web bug into full cluster takeover, and from there into compromise of the cloud account behind it.
This guide walks through how to actually test a Kubernetes environment: the attack surface, the misconfigurations that show up in nearly every audit, the container escape vectors that turn a compromised pod into root on the node, and how the three disciplines—image scanning, runtime testing, and cluster pentesting—fit together.
The Kubernetes Attack Surface
Before you test, map what an attacker sees. A Kubernetes cluster exposes four high-value components, and each one is a distinct target with distinct failure modes.
The API server
The kube-apiserver is the front door to everything. Every kubectl command, every controller, every workload that talks to the cluster goes through it. Testing the API server means checking that anonymous access is disabled, that authentication is enforced (not just RBAC authorization sitting behind an open door), that the --anonymous-auth=false and audit-logging flags are set, and that the endpoint is not needlessly exposed to the public internet. A surprising number of managed and self-hosted clusters still leave the API server reachable from anywhere with only token-based protection.
The kubelet
Each node runs a kubelet, which exposes an API (default port 10250) for managing pods on that node. If the kubelet allows unauthenticated or read-only access (the legacy port 10255), an attacker who reaches a node—or a pod that can route to one—can enumerate running pods, read their environment, and in misconfigured clusters execute commands inside containers. The kubelet is the classic pivot point that kube-hunter probes for.
etcd
etcd is the cluster's database. It stores every object, including Secrets, in plaintext unless encryption at rest is explicitly enabled. Direct access to etcd is equivalent to cluster-admin: you can read every credential and rewrite cluster state. Testing verifies that etcd is reachable only from the control plane, requires mutual TLS, and has --encryption-provider-config configured so Secrets are not sitting in cleartext.
RBAC and identity
Role-based access control is the connective tissue. It decides which subjects can touch which resources. Because RBAC is additive and easy to over-grant, it is the single most common source of privilege-escalation paths in real clusters—covered in depth below.
Common Cluster Misconfigurations
The phrase kubernetes cluster security misconfiguration covers a predictable set of patterns. These are the findings that appear in almost every first-time assessment, ranked roughly by how often they lead to a real compromise.
Privileged and over-capable pods
A pod with securityContext.privileged: true has effectively unrestricted access to the host. Even without full privilege, dangerous capabilities like CAP_SYS_ADMIN, allowPrivilegeEscalation: true, or running as UID 0 give an attacker far more than the workload needs. The fix is a restrictive security context applied everywhere:
hostPath mounts and shared namespaces
A hostPath volume mounts a directory from the node into the pod. Mount /, /var/run/docker.sock, or /etc/kubernetes and the container can read or write the host's filesystem—an immediate escape. The same applies to hostPID, hostNetwork, and hostIPC, which break the isolation boundary between pod and node. Testing flags any workload requesting these unless there is a documented, audited reason (a CNI or monitoring DaemonSet, for instance).
Default service account tokens
By default, every pod gets the namespace's default service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. If that service account has any meaningful RBAC permissions—or if the workload does not need API access at all—the token is free credential material for anyone who pops the pod. Set automountServiceAccountToken: false on workloads that do not call the API, and scope the ones that do.
Missing NetworkPolicies
Out of the box, Kubernetes networking is flat: any pod can reach any other pod in any namespace. Without NetworkPolicies, a single compromised front-end pod can talk directly to your database, your internal admin services, and the cloud metadata endpoint. A default-deny policy per namespace, with explicit allow rules, is the baseline:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Unencrypted Secrets and exposed metadata
Kubernetes Secrets are base64-encoded, not encrypted. Without etcd encryption at rest they are readable by anyone with etcd or backup access. Compounding this, pods that can reach the cloud instance metadata service (169.254.169.254) can often steal the node's IAM role credentials—the bridge from cluster compromise to cloud account compromise.
RBAC: Who Can Do What
Kubernetes RBAC controls access to cluster resources through Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Good testing goes beyond "is anything bound to cluster-admin" and hunts for escalation paths—chains of individually reasonable-looking permissions that combine into full control.
The verbs to watch are escalate, bind, and impersonate. A subject that can create pods can often mount a privileged service account and read its token. A subject that can bind roles can grant itself cluster-admin. A subject with impersonate can act as any user. Other classic paths include the ability to read Secrets cluster-wide, to create or modify ValidatingWebhookConfigurations (intercepting every API request), or to exec into pods running with higher privileges.
Practical RBAC testing answers: does any default service account carry permissions it does not need? Can a namespace-scoped subject reach cluster-scoped resources? Are there wildcard rules (resources: ["*"], verbs: ["*"])? Tools like rbac-tool and kubectl-who-can help enumerate these, but interpreting whether a chain is actually exploitable is where adversarial testing earns its keep.
Container Escape Testing
The most critical class of Kubernetes finding is the container escape vulnerability—breaking out of a container to access the host node, then using that foothold for lateral movement. This is the heart of the container escape vulnerability docker security problem, and it applies whether your runtime is containerd, CRI-O, or Docker.
Escape vectors fall into two buckets. The first is configuration-driven: the container was handed enough access to walk out. A writable /var/run/docker.sock lets a container create a new privileged container on the host. A privileged pod can mount the host's root filesystem and write a SSH key or cron job. hostPID exposes host processes for injection. These are the common, high-probability escapes, and they map directly to the misconfigurations above.
The second bucket is exploit-driven: kernel and runtime CVEs. Historic examples like CVE-2019-5736 (runc /proc/self/exe overwrite) and various cgroups and kernel bugs let an attacker escape even a reasonably configured container. Testing here means knowing which runtime and kernel versions you run, checking them against known escape CVEs, and confirming defense-in-depth controls (seccomp, AppArmor/SELinux, gVisor or Kata for high-risk workloads) are actually enforced rather than set to Unconfined.
A realistic kill chain: an SSRF bug in a web workload reaches the cloud metadata endpoint → steals the node IAM role → the role can pull from a container registry and the pod's service account can list Secrets → a Secret holds a cluster-admin kubeconfig → attacker schedules a privileged pod on every node. Each step is mundane. Chained, it is game over. This is precisely the kind of multi-step path automated single-issue scanners miss.
Container Security Scanning vs Runtime Testing vs Cluster Pentesting
Teams often ask which tool "does Kubernetes security." The honest answer is that there are three different disciplines, they answer different questions, and a mature program runs all three. Understanding container security scanning vs runtime testing—and where cluster pentesting sits—is the key to not wasting budget on overlapping coverage while leaving real gaps.
| Dimension | Image scanning | Runtime testing | Cluster pentesting |
|---|---|---|---|
| Question it answers | Does this image ship known-vulnerable packages? | Is the running workload behaving safely right now? | Can an attacker actually compromise the cluster? |
| When it runs | Build / registry / CI gate | Continuously, in the live cluster | Point-in-time, adversarial |
| What it inspects | Image layers, OS packages, libraries, Dockerfile | Syscalls, process behavior, network flows, drift | RBAC, escape paths, lateral movement, workload exploits |
| Catches | CVEs, outdated deps, secrets in layers | Anomalies, crypto-miners, unexpected egress | Chained, exploitable attack paths end to end |
| Misses | Runtime config, RBAC, logic flaws | Latent misconfigs not yet triggered | Issues outside the test window |
| Example tools | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, manual pentest, Penetrify |
| Automation fit | Fully automatable in CI | Always-on agent | Scheduled + continuous AI-driven |
Image scanning is cheap, fast, and belongs in every pipeline—but a perfectly scanned image still runs as root with a hostPath mount if you let it. Runtime testing catches what is happening but tells you little about what could happen. Cluster pentesting is the only one of the three that proves exploitability by chaining findings the way an attacker would. None replaces the others.
Tooling: kube-bench, kube-hunter, and Trivy
A solid container security scanning workflow for kubernetes usually combines three open-source workhorses, each with a clear role. They are complementary, not competing.
kube-bench
kube-bench runs the CIS Kubernetes Benchmark against your nodes and control plane. It is a configuration auditor: it checks API server flags, kubelet settings, file permissions on cluster components, and etcd configuration against a well-known hardening standard. Run it on every node and in CI against your cluster manifests. It tells you whether your cluster is built to spec; it does not tell you whether the spec is being attacked.
kube-hunter
kube-hunter is an active reconnaissance tool. Pointed at a cluster (or run as a pod inside it), it probes for exposed kubelets, accessible API endpoints, the metadata service, and known weak points, then reports what an attacker could discover. It is closer to a network scanner for Kubernetes than a full pentest—excellent for surface mapping, limited for proving end-to-end exploitation.
Trivy
Trivy is the Swiss-army scanner: container image CVEs, IaC and Kubernetes manifest misconfiguration scanning, exposed secrets, and SBOM generation. It is the natural choice for the image-scanning column above and integrates cleanly into build pipelines. Pair it with kube-bench for configuration coverage and kube-hunter for live reconnaissance, and you have a strong open-source baseline.
What this trio does not do is reason about your application logic, chain a web-layer bug into a cluster takeover, or adapt its approach the way a human attacker would. That is the gap the next section addresses. For wiring these scanners into your delivery pipeline, see our guide to CI/CD penetration testing and pipeline security automation.
The Workload Web and API Layer
Here is the part most Kubernetes security programs underweight: the workloads themselves. Your cluster is hosting web apps and APIs, and those are where the initial foothold usually comes from. An attacker rarely starts with a stolen kubeconfig—they start with an SSRF, an auth bypass, or an injection bug in a service you deployed, and then pivot into the cluster using the misconfigurations above.
This is exactly where autonomous AI penetration testing fits. Configuration scanners and CIS benchmarks cannot find a business-logic auth bypass in your checkout service; they were never designed to. AI-driven testing exercises the running web and API endpoints inside your workloads the way an attacker would—probing authentication, authorization, injection, and SSRF—and then follows the chain: from a workload bug, to the mounted service account token, to the cluster permissions that token unlocks, to the cloud IAM role behind the node.
That continuous, exploit-chaining coverage of the application layer complements—rather than replaces—your kube-bench and Trivy pipeline. For the API-specific dimension, our deep dive on automating API security testing covers the OWASP API Top 10 and how to make that testing repeatable across deployments.
If you are still mapping out which workloads and clusters to prioritize, the companion post on container security testing for Docker images and runtime protection covers the image and runtime sides in more depth, and our walkthrough of fixing common Kubernetes cluster misconfigurations gives concrete remediation steps for the issues above.
Testing Kubernetes with Penetrify
Penetrify's Kubernetes security testing covers RBAC, pod security, network policies, secrets management, container escape vectors, and managed Kubernetes configurations (EKS, AKS, GKE). Testing evaluates both the Kubernetes layer and the cloud provider integration layer—because a Kubernetes compromise often leads to cloud account compromise through linked service accounts and IAM roles.
The cost difference is the reason teams automate it. A traditional manual Kubernetes pentest from a consultancy typically runs $5,000 to $50,000 per engagement and gives you a point-in-time snapshot that is stale the moment you ship your next deployment. Penetrify runs continuously from $100 to $5,000 per month, re-testing every time your cluster changes. For a fuller breakdown of what drives those numbers, see our penetration testing cost comparison.
The Bottom Line
Kubernetes adds an entire orchestration layer of attack surface on top of your cloud infrastructure. Testing it requires three complementary disciplines—image scanning, runtime monitoring, and cluster penetration testing—plus adversarial testing of the web and API workloads that give attackers their first foothold. Configuration scanners harden the build; only exploit-chaining pentesting proves what an attacker can actually reach.
Penetrify combines autonomous AI pentesting of your workloads with cluster and cloud-integration testing, continuously and from $100/mo—so your Kubernetes security keeps pace with every deployment instead of every annual audit.