Kubernetes has become the default infrastructure for deploying modern applications at scale. It has also introduced a security model fundamentally different from the one most security teams were trained on. Traditional network penetration testing finds open ports and vulnerable services. Traditional application testing finds injection flaws and broken authentication. Kubernetes penetration testing finds something different: misconfigurations in a distributed control plane that can give an attacker cluster-level access from a single compromised container.
The most serious Kubernetes breaches in recent years were not caused by CVEs in the Kubernetes codebase. They were caused by overpermissioned service accounts, unauthenticated API server exposure, privileged pods that allow container escape to the host, and supply chain weaknesses where malicious or vulnerable images entered production clusters. These are configuration and architecture failures that standard penetration testing methodology was not designed to find.
This guide covers what Kubernetes penetration testing actually tests at each layer of the container environment, why the methodology differs from application and network testing, the attack paths testers follow, and what findings to expect.
A traditional penetration test asks: can an attacker get into this system? Kubernetes penetration testing asks a different question: given that an attacker has already reached a container in the cluster, what can they reach next?
This starting assumption (initial access to a container rather than zero access from the internet) reflects the realistic threat model for Kubernetes environments. Containers run application code. Application code has vulnerabilities. An application vulnerability that gives an attacker remote code execution inside a container gives them a foothold on the cluster's internal network, where the Kubernetes control plane, other workloads, and the underlying cloud infrastructure are all potentially reachable.
The question is what controls contain that foothold and what allows it to expand. Kubernetes penetration testing systematically tests whether those controls hold.
Role-Based Access Control is the access control mechanism for the Kubernetes API, and it is the single most consistently problematic area in Kubernetes security assessments. The principle of least privilege is violated in Kubernetes RBAC at higher rates than in almost any other access control system, primarily because Kubernetes RBAC is complex, the consequences of misconfiguration are non-obvious, and the default posture in many cluster deployments starts too permissive and is never tightened.
What RBAC testing examines:
Service account permissions: every pod in Kubernetes runs as a service account. By default, pods are assigned the default service account, which in many clusters has been granted excessive permissions through roles and role bindings accumulated over time. Testing examines what permissions each service account holds and whether those permissions are greater than what the workload requires.
Privilege escalation paths: specific combinations of RBAC permissions allow a lower-privilege identity to escalate to higher privilege. The most common: permission to create pods (allows running a privileged pod), permission to bind roles (allows granting oneself additional permissions), permission to create/patch deployments (allows injecting additional environment variables or volume mounts into existing workloads). These escalation paths are tested by enumerating all service accounts and their permissions and mapping which accounts could expand their own access.
Cluster-admin bindings: any service account, user, or group bound to the cluster-admin ClusterRole has full control of the entire cluster. Every cluster-admin binding should be justified. Testing identifies all cluster-admin bindings and evaluates whether each is necessary.
Wildcard permissions in RBAC: roles granting verb: ["*"] or resource: ["*"] are frequently over-permissive. Testing identifies all wildcard permissions and the workloads running with those permissions.
The pod specification controls what a container can do at the OS level, and misconfigured pod specifications create container escape paths that allow an attacker inside a container to reach the underlying host node.
What pod security testing examines:
Privileged containers: a container running with securityContext.privileged: true has full access to the host kernel. This is the widest container escape path available and should be present only in containers with explicit, justified operational requirements (typically, host-level system tools and some CNI plugins). Testing identifies all privileged containers and validates whether the privilege is justified.
Host namespace sharing: pods configured with hostPID: true, hostIPC: true, or hostNetwork: true share the corresponding host namespace with the underlying node. A pod with hostPID: true can observe and signal all processes on the host. A pod with hostNetwork: true can bind to host ports and bypass network policy controls. Testing identifies all pods with host namespace access.
allowPrivilegeEscalation: containers that allow privilege escalation can run setuid binaries that escalate to root. Combined with other conditions, this creates escape paths. Testing validates that allowPrivilegeEscalation: false is set for containers that do not require it.
Capabilities: Kubernetes allows granting specific Linux capabilities to containers without full privilege. Some capabilities (SYS_ADMIN, NET_ADMIN, SYS_PTRACE) are dangerous when combined with other conditions and should be audited. Testing maps all capability grants and identifies dangerous combinations.
Container root: containers running as root (UID 0) are a higher-risk baseline than containers running as non-root users. Testing identifies containers running as root and whether user namespaces or other mitigations are in place.
The Kubernetes API server is the central control plane component through which all cluster management operations flow. If an attacker can reach the API server and authenticate, they control the cluster.
What API server testing examines:
Unauthenticated access: the API server should never allow anonymous requests to non-public endpoints. Testing confirms whether anonymous authentication is disabled and whether unauthenticated requests are rejected.
API server network exposure: the API server typically listens on port 6443. Testing checks whether the API server is accessible from the internet, from workload network segments that should not have API server access, or from any network position that is broader than necessary.
Authentication configuration: Kubernetes supports multiple authentication mechanisms. Testing examines which mechanisms are enabled and whether they are configured securely.
Audit logging: API server audit logs record all API requests with identity, action, and resource. Testing confirms that audit logging is enabled, that the audit policy captures security-relevant events (authentication failures, privilege escalation attempts, secret access), and that logs are shipped to a location that could not be tampered with by an attacker who compromises the cluster.
Admission controllers: admission controllers intercept API requests before objects are created and can enforce security policies (preventing privileged pod creation, requiring specific labels, enforcing resource limits). Testing identifies which admission controllers are enabled and whether they are configured to enforce the intended policies.
Kubernetes Secrets are the native mechanism for storing sensitive configuration values: database credentials, API keys, TLS certificates. By default, Kubernetes Secrets are stored in etcd with base64 encoding, which is not encryption.
What secrets testing examines:
Secrets accessible to service accounts: testing enumerates which secrets each service account can read, and whether workloads have access to secrets they do not require for operation.
Secrets mounted as environment variables vs volumes: secrets mounted as environment variables are visible in process listings on the host (via /proc) and in container inspection output. Secrets mounted as volumes are more restricted. Testing identifies secrets mounted as environment variables unnecessarily.
etcd encryption at rest: Kubernetes supports encrypting Secret objects in etcd using EncryptionConfiguration. Testing verifies whether encryption at rest is configured and which encryption provider is used.
Third-party secrets management integration: organisations that use HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager for application secrets should use these systems rather than native Kubernetes Secrets for sensitive values. Testing identifies whether native Kubernetes Secrets are used for values that should be in a dedicated secrets management system.
By default, Kubernetes has no network isolation between pods. Any pod can reach any other pod in the cluster unless network policies explicitly restrict the traffic. This means that a compromised pod can attempt connections to any other workload, the API server, and cloud provider metadata endpoints without any built-in network restriction.
What network policy testing examines:
Network policy existence and coverage: testing identifies namespaces and workloads with no network policy applied, creating unrestricted communication paths.
Default deny posture: the most secure baseline is a default-deny network policy that blocks all traffic not explicitly permitted. Testing checks whether default-deny policies are in place.
Egress restrictions: network policies that restrict egress prevent compromised pods from exfiltrating data or reaching external command and control infrastructure. Testing validates whether egress restrictions are applied to sensitive workloads.
Lateral movement paths: from a simulated compromised pod, testing maps which other workloads are reachable, identifying the blast radius of a single container compromise.
Cloud provider metadata endpoint access: the IMDS endpoint at 169.254.169.254 is reachable from pods in AWS, Azure, and GCP clusters unless explicitly blocked. Reaching this endpoint from a pod allows retrieval of the node's instance role credentials. Testing confirms whether pods can reach the metadata endpoint and what credentials are accessible from the node role.
Container images define what code runs in the cluster. Vulnerable or malicious images are a supply chain attack vector that introduces risk at the workload level regardless of how well the cluster is configured.
What supply chain testing examines:
Image vulnerability scanning: testing identifies known CVEs in base images and installed packages across workloads in the cluster. Images running with critical or high severity CVEs, particularly those involving privilege escalation or remote code execution vulnerabilities, represent exploitable risk inside containers that are already running.
Image source and registry controls: testing verifies whether admission controllers restrict which container registries images may be pulled from. Unrestricted registry access allows deployment of arbitrary images, including attacker-controlled ones.
Image integrity verification: testing checks whether image signatures are verified before deployment, preventing use of modified or substituted images.
Image build pipeline security: for internally built images, testing examines the build pipeline for credential exposure (secrets in Dockerfiles or build arguments), whether base images are regularly updated, and whether the build pipeline itself is hardened.
This supply chain dimension connects to the broader application security testing layer. SAST tools: what they catch and what they miss covers how static analysis applies to container image contents and the build pipeline, and where it falls short for runtime container security.
To make the testing methodology concrete, here is the attack path a Kubernetes penetration tester follows from initial container access:
Step 1: Initial access. Exploit an application vulnerability in a container running in the cluster. The foothold gives code execution within the container and access to the container's environment, including environment variables, mounted secrets, and the service account token at /var/run/secrets/kubernetes.io/serviceaccount/token.
Step 2: Service account enumeration. Use the mounted service account token to query the API server: what permissions does this service account hold? In many clusters, the answer is more than expected: roles accumulated through kubectl apply -f operations that granted permissions for convenience and were never reviewed.
Step 3: Privilege escalation within the cluster. If the compromised service account can create pods, bind roles, or patch deployments, use those permissions to gain higher-privilege access. Creating a pod that mounts the node's root filesystem, for example, provides full host access from within a container.
Step 4: Lateral movement. Enumerate what other workloads are reachable from the compromised pod through the cluster network. Without network policies, the entire pod network is reachable. With network policies, test whether the policies have gaps.
Step 5: Control plane access. If the service account has sufficient permissions, access etcd directly, modify deployments, extract secrets, or create persistent access through new service accounts.
Step 6: Cloud infrastructure pivot. From the compromised node, reach the cloud provider metadata endpoint. Retrieve the node instance role credentials. Use those credentials to pivot to the underlying AWS, Azure, or GCP account. The blast radius of a single compromised container in a cluster with misconfigured RBAC and no metadata endpoint restriction can extend to the entire cloud account.
This attack path is what Kubernetes penetration testing validates at each step: where does the path break? Where do controls hold? The findings map exactly which misconfigurations must be remediated to reduce the blast radius.
Three properties make Kubernetes penetration testing distinct from the testing types that most security programmes already have in place.
The threat model starts inside the perimeter. Application penetration testing starts from outside the application. Network penetration testing starts from outside the network perimeter. Kubernetes penetration testing starts from a position inside the cluster, because the realistic attacker who exploits an application vulnerability already has that position.
The attack surface is configuration, not code. Application vulnerabilities are in code: SQL injection, broken authentication, business logic flaws. Kubernetes vulnerabilities are almost entirely in configuration: RBAC bindings, pod specifications, network policy gaps, API server settings. This means the testing methodology is fundamentally different: not exploit development but configuration analysis combined with exploitation of misconfiguration.
The blast radius scales differently. An application vulnerability gives an attacker access to that application's data. A Kubernetes configuration vulnerability can give an attacker access to every workload in the cluster, every secret in the cluster, and the underlying cloud infrastructure. The impact of a single finding is potentially much larger than in application or network testing.
The security gaps DAST and standard testing misses covers why container environment security requires testing methodology beyond what application-layer tools provide. API vulnerabilities standard penetration tests miss covers the API security dimension that Kubernetes clusters expose through the API server and application APIs running as services within the cluster.
Kubernetes penetration testing is the deep-dive companion to cloud security assessment. The cloud security assessment overview covers container and Kubernetes security as one of eight technical domains. Organisations with significant Kubernetes deployments should commission dedicated Kubernetes penetration testing to cover RBAC, pod security, network policy, and supply chain at the depth that a broad cloud assessment cannot.
The two assessments use different starting points: cloud security assessment starts from cloud infrastructure configuration (IAM, storage, network); Kubernetes penetration testing starts from workload access inside the cluster. Together they cover the full container environment attack surface from two complementary directions.
Network penetration testing: what it covers and how it's done covers the network layer that Kubernetes network policies extend into the container environment. The cluster network fabric sits on top of the physical or virtual network infrastructure, and network penetration testing covers the underlying layer that Kubernetes network policy builds on.
For organisations shipping container-based applications continuously, the testing cadence challenge is the same as for web application security: new images are deployed, new configurations are applied, new service accounts are created. Continuous penetration testing and how it differs from annual pentests covers the deployment-triggered model, and how autonomous pentesting works in a DevSecOps pipeline covers how agentic testing integrates with the CI/CD workflows that build and deploy container images.
Agentic pentesting and continuous security validation covers how continuous exploitation validation applies to the application layer running inside containers. For penetration testing services in the US covering container and Kubernetes environments alongside application security, VAPT services, and agentic penetration testing for the continuous application layer, the 10x Pentest platform covers the application security layer. See pricing or get in touch to discuss scoping Kubernetes security assessment alongside your application and cloud security testing programme. What is inside a VAPT report covers the evidence standard that applies across both cloud and container security findings.
Q1. What is Kubernetes penetration testing?
Kubernetes penetration testing is a security assessment of a Kubernetes cluster environment that tests RBAC configuration, pod security settings, API server exposure, secrets management, network policy enforcement, and supply chain security. It starts from the realistic threat model of an attacker with initial access to a container in the cluster, and tests what that attacker could reach: other workloads in the cluster, the Kubernetes control plane, etcd and the secrets it contains, and the underlying cloud infrastructure through node instance credentials. It differs from application and network penetration testing because the attack surface is primarily configuration rather than code, and the blast radius of a single finding can extend to the entire cluster and cloud account.
Q2. What does Kubernetes penetration testing cover?
A comprehensive Kubernetes penetration test covers six domains: RBAC and identity configuration (service account permissions, privilege escalation paths, cluster-admin bindings); pod security and workload configuration (privileged containers, host namespace sharing, capability grants, root container execution); API server security (anonymous authentication, network exposure, audit logging, admission controllers); secrets management (secret access permissions, etcd encryption, environment variable secret exposure); network policy and segmentation (default-deny posture, lateral movement paths, cloud metadata endpoint access); and supply chain security (image vulnerability scanning, registry controls, image signature verification).
Q3. How does Kubernetes penetration testing differ from application penetration testing?
Application penetration testing targets vulnerabilities in application code: injection flaws, authentication bypass, business logic vulnerabilities, API security gaps. Kubernetes penetration testing targets misconfigurations in the container orchestration layer: RBAC bindings that grant excessive permissions, pod specifications that allow container escape to the host, network policy gaps that allow lateral movement between workloads, and API server configurations that allow unauthenticated or over-permissioned access. Application testing starts from outside the application. Kubernetes testing starts from inside the cluster, modelling an attacker who has already compromised a container through an application vulnerability and is now trying to expand their access.
Q4. What are the most serious Kubernetes security vulnerabilities?
The highest-impact Kubernetes security findings are: privileged pods or pods with host namespace access that allow container escape to the underlying node; service accounts bound to cluster-admin or equivalent roles that grant full cluster control from a single compromised workload; API server accessible from the internet or from broad internal network segments without strict network controls; missing network policies that allow any compromised pod to reach the cloud provider metadata endpoint and retrieve node instance credentials; and etcd exposed without encryption at rest or with overly permissive access, allowing direct extraction of all cluster secrets. These findings can give an attacker full control of the cluster and the underlying cloud account from a single container compromise.
Q5. How often should Kubernetes penetration testing be done?
Annual Kubernetes penetration testing is the common baseline, with additional testing following significant cluster architecture changes (major Kubernetes version upgrades, changes to RBAC configuration, deployment of new critical workloads, cluster migration). The RBAC and network policy drift that occurs as new workloads are deployed and teams grant permissions for operational convenience means that cluster configuration changes more continuously than other infrastructure types. Continuous RBAC auditing and network policy validation tools complement periodic penetration testing by catching drift between assessment cycles.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
