I'm planning a penetration test for a Kubernetes environment and want to define the scope realistically. Since pods and services may receive changing IP addresses, should the assessment focus on stable assets such as the Kubernetes API server, worker nodes, ingress controllers, load balancers, and node ports? For pod-level testing, is it better to use Kubernetes service discovery and the API rather than traditional IP-based scanning? I'd also like to understand what teams typically include or exclude, including control-plane security, RBAC, network policies, container images, CI/CD pipelines, and the underlying node operating systems.
4 Answers
Avoid chasing pod IPs directly. Enumerate services and workloads through Kubernetes-aware discovery, then test the exposed service endpoints. This reflects how an attacker with appropriate cluster access would discover workloads and avoids missing pods as they are rescheduled.
Start with the stable control points: the API server, ingress or gateway, load balancers, worker nodes, node ports, RBAC, and network policies. Those assets provide the structure needed to discover and assess the more temporary parts of the cluster.
A thorough scope should cover the control plane, node operating systems, ingress and service exposure, authentication, authorization, secrets handling, network segmentation, and container runtime settings. It is also worth reviewing image provenance, package vulnerabilities, registry controls, and CI/CD permissions, since a compromise can originate in the software supply chain and move inward.
The exact tools matter less than testing the actual attack surface. Define the assessment by exposure and trust boundaries—external entry points, internal services, cluster-to-node paths, and workload-to-workload access—rather than by a fixed IP list. Make sure the authorization explicitly covers the cluster, cloud resources, registries, pipelines, and any third-party managed components involved.
That makes sense—the goal is to assess the discovery and access paths rather than maintain a list of short-lived pod addresses.