I'm planning a penetration test for a Kubernetes environment and want to define the scope realistically. Since pods and some services may receive changing IP addresses, should testing focus on stable components such as the Kubernetes API server, worker nodes, ingress controllers, load balancers, and other persistent endpoints? How should pod and service discovery be handled when traditional IP-based scanning is unreliable? Should testers rely on Kubernetes service discovery and API enumeration instead, and what components are normally included or excluded from a Kubernetes assessment? I'm especially interested in practical approaches to asset discovery and scope definition for internal environments.
4 Answers
Dynamic pod addresses usually aren’t worth treating as standalone assets. If you have authorized cluster access, enumerate services, endpoints, namespaces, workloads, and policies through the Kubernetes API. That better reflects how an attacker who gains cluster access would move through the environment.
A thorough assessment should cover more than network exposure. Include container images and package provenance, the CI/CD path, registry permissions, secrets handling, admission controls, workload identities, RBAC, and opportunities for container-to-node or pod-to-pod escalation. Host and control-plane testing should still be scoped separately.
The scope should be based on attack surfaces and trust boundaries rather than a particular scanning tool. Define whether the test starts externally, from a network position inside the cluster, or with authenticated Kubernetes access, then test each layer accordingly: ingress, services, workloads, control plane, nodes, identities, and supporting delivery systems.
Start with the stable control points: the API server, ingress or gateway, load balancers, worker-node operating systems, exposed NodePorts, RBAC, and network policies. Once those are mapped, use the cluster’s service discovery to identify workloads instead of trying to chase pod IPs directly.
That layered approach makes sense. I’ll document the assumed starting access and separate external exposure testing from authenticated cluster and node-level testing.