Kubernetes Penetration Testing: How Attackers Hit Clusters

Kubernetes penetration testing is an authorised, methodology-driven attack simulation against a cluster's API server, kubelet, etcd, RBAC configuration, and workloads — distinct from a hardening checklist because it proves what an attacker can actually reach, not just what's misconfigured on paper. Real-world cluster compromises follow a repeatable chain: find an exposed component, abuse over-permissioned RBAC, steal a service account token, escalate to node access, then move laterally. Indian teams running Kubernetes on managed cloud platforms are exposed to this exact chain, and this guide walks through it, mapping every attack step to the defence that closes it.

Why Kubernetes Penetration Testing Needs Its Own Methodology

Kubernetes clusters aren't a single application — they're a control plane, a container runtime, a networking layer, and an identity system bundled together, each with its own attack surface. A web app pentest that stops at the ingress misses the API server behind it, the kubelet agent on every node, the service account tokens mounted into every pod, and the RBAC bindings deciding what a compromised workload can do next. A dedicated Kubernetes pentest walks this chain: enumerate exposed components, abuse identity, escalate from container to node, extract secrets — the same sequence a real attacker follows.

Step One: Finding the Exposed Component

Every Kubernetes attack chain starts with reconnaissance against the components attackers scan for first: the API server, kubelet, etcd, and the Dashboard.

1. API server (default port 6443) — the front door to the cluster. Reachable from the internet without proper authentication, or with anonymous access enabled, it hands an attacker a direct path to cluster resources.
2. Kubelet API (port 10250, read-only 10255) — runs on every node; if unauthenticated, it allows arbitrary command execution inside any pod on that node via the exec and run endpoints.
3. etcd (port 2379) — the cluster's datastore, holding every Secret and resource definition in plaintext unless encryption at rest is configured. An exposed, unauthenticated etcd instance is the entire cluster's data in one place.
4. Kubernetes Dashboard — historically deployed with a permissive service account by default; a publicly reachable dashboard with skip-login enabled gives an attacker a GUI straight into cluster administration.

kubectl cluster-info dump
nmap -p 6443,10250,10255,2379,2380 <node-ip>
curl -k https://<node-ip>:10250/pods

Step Two: RBAC Abuse and Privilege Escalation

Once inside the cluster — through a compromised pod, a leaked kubeconfig, or an exposed API server — the next move is enumerating what the identity is allowed to do. RBAC is granular by design, but most clusters accumulate over-permissioned bindings: cluster-admin granted for convenience, service accounts bound to roles broader than the workload needs, or wildcard verbs (*) on custom roles.

kubectl auth can-i --list
kubectl get clusterrolebindings -o wide
kubectl get rolebindings --all-namespaces -o wide

The critical checks: does the identity have create on pods, bind on roles, or impersonate on users? Any of these chains into a privilege escalation. A service account that can create pods can spin one up mounting a more privileged service account's token, or running privileged with a hostPath mount into the node's filesystem — turning namespace-scoped access into node-level compromise.

Step Three: Service Account Token Theft

Every pod, unless configured otherwise, gets a service account token automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token authenticates the pod to the API server with whatever RBAC permissions its bound service account carries — the single most valuable artefact inside a compromised container.

cat /var/run/secrets/kubernetes.io/serviceaccount/token
kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) get pods --all-namespaces

Once extracted, the token can be replayed against the API server directly, often from outside the cluster, giving persistent access that survives the original pod being killed. Clusters leaving automountServiceAccountToken: true on workloads that never call the API — most application pods, in practice — hand out unnecessary, exploitable credentials by default.

Step Four: Container-to-Node Escape

A stolen token or initial RCE inside a container is valuable, but the higher-value target is the underlying node — full host access means access to every other pod scheduled on it. Common escape vectors:

1. Privileged containers. A pod running with privileged: true has near-full access to host devices and kernel capabilities — escaping to the node is close to trivial.
2. hostPath volume mounts. Mounting the host filesystem, especially / or /var/run/docker.sock, gives direct read/write access to the node; the socket mount alone allows spinning up new privileged containers on the host.
3. hostPID / hostNetwork. Sharing the host's process or network namespace breaks container isolation, exposing host processes and interfaces to the container.
4. Dangerous capabilities. CAP_SYS_ADMIN and similar, granted without full privileged mode, can still chain into a node escape through kernel-level operations.

kubectl get pods -o jsonpath='{.items[*].spec.containers[*].securityContext}'
kubectl get pods -o json | grep -i hostpath

Step Five: Secrets Extraction

With node or elevated API access, the next target is Secrets — API keys, database credentials, TLS certificates, cloud tokens. Kubernetes Secrets are base64-encoded, not encrypted, by default; anyone who can read one decodes it in one command.

kubectl get secrets --all-namespaces
kubectl get secret <name> -o jsonpath='{.data}' | base64 -d

If etcd encryption at rest isn't configured, every Secret also sits in plaintext inside etcd's data files on disk, reachable to anyone with node-level filesystem access — a second path to the same data that bypasses the API entirely.

Step Six: Lateral Movement

Cluster network policies are permissive by default — without an explicit NetworkPolicy resource, every pod can reach every other pod across every namespace. An attacker who's compromised one workload uses this default-allow posture to reach adjacent services and internal APIs never meant to sit inside that workload's blast radius. Lateral movement inside a cluster is often faster than across a flat network, because most teams assume the cluster boundary is itself a security boundary — it isn't, without explicit network policies enforcing it.

CERT-In publishes advisories on container and orchestration vulnerabilities that Indian Kubernetes teams should track alongside routine patch management.

Attack Chain to Remediation

Container and orchestration platforms fall squarely inside that unaudited majority — most Indian teams running Kubernetes have never had the cluster itself, as opposed to the applications on it, independently tested.

Attack Surface Distribution Across a Typical Cluster

Based on common findings across authorised Kubernetes engagements, misconfigured identity and access controls dominate the exploitable surface more than any single exposed port:

Attack Vector to Defence Mapping

Where an External Kubernetes Pentest Adds Value

Cluster configuration drifts constantly — a new namespace gets a broad ClusterRoleBinding during a rushed deploy, a debugging pod gets privileged: true and is never cleaned up, a NetworkPolicy is deleted during troubleshooting and doesn't return. Internal reviews catch some of this; a structured, independent penetration test — walking the exact chain above, delivered with a CERT-In empanelled partner where regulatory submission is required — catches what accumulates between audits.

Bachao.AI builds cluster-level attack surface visibility into its continuous VAPT pipeline, so Indian engineering teams get identity, RBAC, and container-escape testing without a dedicated cluster security engineer running manual audits every sprint. Dhisattva AI Pvt Ltd built the platform around the reality that most Indian teams adopted Kubernetes for scale and never tested what that layer exposes.

Next Steps

Kubernetes penetration testing has to walk the same chain an attacker walks — exposed component, RBAC abuse, token theft, node escape, lateral movement — because testing each layer in isolation misses the escalation paths that make clusters worth attacking. Run this methodology against your own authorised cluster on a fixed schedule, and treat every ClusterRoleBinding and mounted service account token as something needing a documented reason to exist.

Want visibility into what your cluster actually exposes to an attacker? Get a free VAPT scan, or browse the blog for more hands-on security methodology. If your cluster processes personal data under India's privacy law, also review our DPDP compliance guide.