A traditional network penetration test asks a simple question: what can I reach, and what can I do once I get there? That question still matters in a cloud-native environment, but the answers changed shape. There is no server to own in the old sense. There is a control plane that schedules workloads, an identity system that hands out credentials to those workloads, and a flat internal network where hundreds of short-lived processes talk to each other. Compromise a container and you have not compromised a host — you have acquired a foothold and a set of permissions, and what happens next depends entirely on how the cluster was configured.
The Attack Surface Is Not the Host
On a conventional server, the interesting assets are on the box: files, credentials, running services. In Kubernetes, the interesting assets are usually somewhere else, and the container is just the thing holding the token that reaches them.
That inversion changes what a tester looks for. Local privilege escalation inside a pod matters far less than the service account mounted into it. A container running as root is worth noting; a container running as root with a service account that can create pods in kube-system is a full cluster compromise waiting for someone to notice. The question stops being "can I become root here" and becomes "what does this workload's identity let me do to everything else."
What We Look For
- Exposed control plane components: kubelets answering on the read-write port, etcd reachable without mutual TLS, dashboards published to the internet, or API servers with anonymous authentication left enabled. Each of these collapses the distance between an outsider and total cluster control.
- Overly permissive RBAC: wildcard verbs on wildcard resources, cluster-admin bound to default service accounts, or the ability to create or escalate role bindings. RBAC misconfiguration is the most reliable path we find from one pod to the whole cluster.
- Container escape conditions: privileged containers, hostPath mounts of sensitive directories, hostPID or hostNetwork, a mounted container runtime socket, or capabilities that let a process manipulate the kernel directly.
- Secrets in the wrong places: credentials in manifests, environment variables, ConfigMaps, or committed to the repository that renders the chart. Kubernetes Secrets are base64-encoded, not encrypted, and anyone who can read them in a namespace has them.
- East-west movement: by default every pod can talk to every other pod. Without network policies, a single compromised front-end workload can reach internal services, databases, and the metadata endpoint.
- Cloud identity bleed: workload identity or IRSA bindings that grant a pod broader cloud permissions than its function requires, turning a container foothold into an account-level one.
Why an External Test Isn't Enough
An external network test against a cluster tells you about the ingress. That is worth knowing — exposed dashboards and management ports are real findings and we do find them. But if the perimeter holds, the test ends, and everything described above stays untested.
The realistic threat model is not a stranger scanning your load balancer. It is a vulnerable dependency in one application container, a leaked CI token, or a compromised developer laptop. In every one of those cases the attacker starts inside. So we test from there too. An assumed-breach engagement drops us into a pod or gives us a low-privilege service account, and we work outward the way an attacker would: enumerate permissions, read what we can, move laterally, reach for the control plane. This pairs directly with our network penetration testing services, because the internal and external views answer different questions and you need both.
Images and the Supply Chain
Everything running in the cluster came from somewhere, and that pipeline is part of the attack surface. Base images carry known vulnerabilities and sometimes carry credentials baked in during a build. Registries permit unauthenticated pulls or, worse, pushes. Tags are mutable, so :latest today is not what it was last week. Admission control frequently does not verify that an image came from a source you trust.
The CI/CD system deserves the same scrutiny. A pipeline that can deploy to production holds credentials that can deploy to production, and pipelines are often less hardened than the clusters they target. If an attacker can influence what gets built, the cluster's runtime controls are largely irrelevant.
How We Approach It
We do not run a scanner against the API server and call it a cloud-native assessment. Configuration review gives us the map: RBAC bindings, admission policy, network policy, workload specifications. Then we test the map against reality, because what is declared and what is running diverge more often than teams expect. Findings get reported with the actual path — this pod, this service account, this permission, this outcome — so remediation is a specific change rather than a general aspiration. Our methodology covers how we structure that work and what you receive at the end.
Getting Started
If you run workloads in Kubernetes and your last test was a scan of your public IP ranges, you have a gap. It is not a small one. Contact us and we will scope an engagement that reflects how your environment is actually built and how it would actually be attacked.