Kubernetes Pentesting: Attack Paths in Real-World Clusters
From a foothold in a single pod to cluster-admin: the recurring Kubernetes attack paths we exploit on engagement, and how to close them.
The cluster threat model
Kubernetes pentesting starts where the application pentest ends: assume a foothold in a single pod via a compromised app or supply-chain dependency.
From there, the realistic objective is escalation to namespace admin, cluster admin, and cloud account control via the node IAM role.
From pod to namespace
Default service-account tokens mounted into every pod give attackers an immediate API client. Excess RBAC (list/get pods/secrets across namespaces) accelerates lateral movement.
Network policies are usually missing or permissive. Once a pod can reach the apiserver, kubelet or metadata service, the blast radius is the cluster.
Privilege escalation paths
Common paths: container escape via privileged or hostPath mounts, abusing pod/exec on a privileged pod, mutating webhooks injecting malicious sidecars, and impersonation via bound roles.
ImagePullSecrets and ServiceAccount tokens with cluster-wide reach are routinely over-scoped. We map every credential reachable from each namespace.
Data and secret exposure
Secrets stored as base64 in etcd, mounted into pods that do not need them, are the easiest exfil targets. KMS-encrypted etcd is the floor, not the ceiling.
ConfigMaps containing API keys, S3 buckets reachable via the node IAM role, and CI/CD pipelines with cluster-admin kubeconfigs are recurring exfiltration vectors.
Hardening checklist
Restricted Pod Security Standard. Default-deny NetworkPolicy. IRSA / Workload Identity instead of node IAM. Disable automountServiceAccountToken by default. Image signing and admission control.
Run a Kubernetes-specific pentest after every major version upgrade and after any change to RBAC, admission control or networking. Generic cloud pentests will miss most of this.