A Kubernetes penetration test scoped like a network or web application test will report open ports and missing headers while missing the RBAC bindings, service account tokens and escape paths that turn one compromised pod into control of the whole cluster. Clusters combine a control plane API, node agents, workload identities, admission policy and a cloud account underneath, and the most damaging findings are usually chains across those layers rather than single vulnerabilities. This guide is for security leaders, platform owners and assessors who commission or review Kubernetes tests: how to choose the starting positions, which areas to put in scope, how to keep a live cluster safe during testing, and what good evidence and reporting look like. It is written from the buyer and defender side and does not describe attack procedures or tooling. For provider testing rules and cloud IAM paths, read the Cloud Penetration Testing Guide first; for the controls being tested, the Kubernetes Security Guide.
Key takeaways
- Test from more than one starting point. An external view, a compromised pod, a developer kubeconfig and a compromised node each answer a different question; most real impact appears in the assumed-breach positions.
- RBAC and tokens are the core of scope. The Kubernetes project lists eleven RBAC privilege escalation risks, from listing secrets to the escalate, bind and impersonate verbs; every test should report which of them each identity holds.
- Configuration review is not a penetration test. CIS benchmark scans find settings drift; a penetration test shows whether those settings combine into a path to cluster-admin, a node or the cloud account.
- Safety rules must be written for a self-healing system. Controllers recreate pods, autoscalers add nodes and admission webhooks sit in every request path, so stop conditions, rate limits and a marker-object rule matter more than in a static network.
- The cluster to cloud boundary is in scope. Node roles, workload identity bindings and metadata access decide whether a cluster finding becomes a cloud account compromise.
What a Kubernetes penetration test covers
A Kubernetes test assesses the cluster as a system: the API server and its authentication, authorisation and admission chain; etcd; the kubelet and container runtime on each node; workloads and their service accounts; network policy; the image supply chain; and the cloud or data centre identity that the cluster and its nodes use. The OWASP Kubernetes Top Ten 2025 is a useful coverage list for scoping conversations:
| OWASP 2025 risk | Scope question for the test |
|---|---|
| K01 Insecure Workload Configurations | Can workloads run privileged, with host namespaces or host paths, as root or without seccomp? |
| K02 Overly Permissive Authorization Configurations | Which identities can read secrets, create workloads, exec into pods or change RBAC? |
| K03 Secrets Management Failures | Where do secrets sit (Secrets, ConfigMaps, environment, images) and who can read them? |
| K04 Lack Of Cluster Level Policy Enforcement | Do Pod Security Admission and admission webhooks block what policy says they block, in every namespace? |
| K05 Missing Network Segmentation Controls | Can a pod in one namespace reach other namespaces, the control plane, node services or the metadata endpoint? |
| K06 Overly Exposed Kubernetes Components | Are the API server, kubelet, etcd, dashboards or add-on UIs reachable from untrusted networks? |
| K07 Misconfigured And Vulnerable Cluster Components | Are control plane, node and add-on versions supported and patched? |
| K08 Cluster To Cloud Lateral Movement | Can a workload or node identity act in the cloud account beyond its purpose? |
| K09 Broken Authentication Mechanisms | Do human and service authentication paths (kubeconfigs, OIDC, certificates, static tokens) resist misuse? |
| K10 Inadequate Logging And Monitoring | Did audit logging and runtime detection see the test, and did anyone respond? |
Two scope decisions shape the rest of the engagement. First, configuration review versus penetration test: a review against the CIS benchmark (the CIS Kubernetes benchmarks include a generic 2.1.0 edition and separate editions for EKS, AKS, GKE, OKE and OpenShift) is cheaper and should come first; the penetration test then shows which deviations are reachable and chain together. Second, black box versus white box: giving testers read access to manifests, RBAC exports and Helm values usually produces more findings per day than making them rediscover the cluster. The Red Team vs Penetration Test vs Vulnerability Scan guide explains where each fits in a wider programme.
Starting positions and threat scenarios
The NSA and CISA Kubernetes Hardening Guidance names data theft, theft of computing power (often for cryptocurrency mining) and denial of service as the usual motives for attacking clusters. Choose starting positions that match how those attacks would begin in your environment:
| Starting position | Question it answers | What the organisation provides | Typical findings |
|---|---|---|---|
| External, no access | What does the internet see of the cluster and its ingress? | Public IP ranges, domains, ingress hostnames | Exposed API server, dashboards or add-on UIs, application flaws leading into pods |
| Compromised workload (assumed breach) | How far can an attacker go from one application pod? | A test pod deployed in a named namespace with that namespace's normal service account and policies | Mounted tokens with excess rights, reachable metadata endpoint, missing network policy, escape-capable pod settings |
| Developer or CI identity | What can a stolen kubeconfig or pipeline credential do? | A test identity with the same RBAC as a real developer or CI runner | Rights to create workloads or exec into pods in sensitive namespaces, secret reads, RBAC changes |
| Compromised node | Does node isolation hold if one node is lost? | Access to a dedicated test node in a non-critical pool | Kubelet credentials reaching beyond their node, secrets of other workloads, cloud node role reach |
| Tenant to tenant | Does multi-tenancy hold between teams or customers? | Two tenant namespaces with normal tenant rights | Cross-namespace network reach, shared service accounts, permissive cluster-scoped roles |
| Supply chain | Can an untrusted image or chart reach production? | Access to the registry and pipeline as a developer | Unsigned images admitted, tags rather than digests, writeable registry paths |
Decision guidance: a small organisation on one managed cluster gets most value from a configuration review plus a single compromised-workload scenario. A platform team running many clusters or hosting several tenants should add tenant-to-tenant and node scenarios, and repeat a reduced assumed-breach test after each major platform change. Regulated or customer-facing multi-tenant platforms justify a full test of every position at least annually.
Test areas to put in scope
Ask testers to assess these areas and to report each finding as a chain from the starting identity to an impact. The table describes what to request, not how to test, with the ATT&CK technique your detection team will recognise.
| Area | What to request | ATT&CK reference |
|---|---|---|
| Exposed components | Reachability and authentication of the API server, kubelets, etcd, dashboards and add-on UIs from each network position | T1133 External Remote Services, T1190 Exploit Public-Facing Application |
| Anonymous and default access | Whether anonymous requests to the API server or kubelets are accepted and what system:anonymous can do | T1078.001 Default Accounts |
| RBAC escalation | For each starting identity, which of the Kubernetes RBAC escalation risks it holds and whether they chain to cluster-admin | T1078.004 Cloud Accounts (where cloud identities map into RBAC) |
| Service account tokens | Which pods mount tokens they do not need, token rights, and use of legacy non-expiring tokens | T1528 Steal Application Access Token |
| Secrets exposure | Secrets readable from each identity, secrets in ConfigMaps, environment variables and images | T1552.007 Container API |
| Workload creation and exec | Whether identities can create pods, jobs or exec into existing pods in sensitive namespaces | T1610 Deploy Container, T1609 Container Administration Command, T1053.007 Container Orchestration Job |
| Escape to node | Whether admission policy allows privileged pods, host namespaces or sensitive host paths, and whether runtime controls stop an escape | T1611 Escape to Host |
| Network segmentation | Cross-namespace and pod-to-control-plane reach, egress to the internet | T1613 Container and Resource Discovery |
| Cloud boundary | Pod access to the metadata endpoint, node role reach, workload identity bindings | T1552.005 Cloud Instance Metadata API |
| Image supply chain | Admission of unsigned or tag-referenced images, registry write rights | T1525 Implant Internal Image |
The Kubernetes RBAC good practices page names the escalation risks to check: listing secrets, workload creation, persistent volume creation, access to the proxy subresource of Nodes, the escalate, bind and impersonate verbs, CSRs and certificate issuing, token request, control of admission webhooks and namespace modification. It also lists object creation denial of service, which is a reason to agree quotas and limits before testing. The Kubernetes RBAC Guide explains each right and how to remove it.
Microsoft's Threat Matrix for Kubernetes is a helpful cross-check that the scope covers every tactic, from initial access through credential access (listing secrets, container service accounts) to impact (resource hijacking, denial of service).
Where identity fits
Most chains in a cluster test run through non-human identities: pod service accounts, the controller manager and add-on identities, kubelet node credentials, CI runners and the cloud roles mapped into the cluster. Ask for an identity inventory in the report: every identity the testers obtained or abused, its source, its effective rights and its expiry. Compare it with the Kubernetes NHI Security Guide and the Kubernetes Service Account Token Guide, and fix the identity first where one token unlocks several findings.
The test also creates identities. Issue testers dedicated, labelled kubeconfigs and service accounts with an expiry matching the test end date, bind them only to the agreed namespaces, and delete them at close. Never give testers a shared administrator kubeconfig, and never hand out the break-glass credential.
Safe execution on a live cluster
Kubernetes reacts to change: controllers recreate deleted pods, autoscalers add nodes when load rises and admission webhooks sit in every create request. Write rules of engagement that account for this, using the Red Team Rules of Engagement Template as a base.
- Environment choice: prefer a staging cluster built from the same infrastructure as code as production. Where production must be tested, limit write scenarios to a dedicated test namespace and node pool.
- Marker objects only: testers prove create, modify or delete rights with a harmless, labelled test object in an agreed namespace, never by changing real workloads, RBAC bindings or admission webhooks.
- No resource exhaustion: no object creation floods, no cryptomining simulation that consumes real capacity, and agreed request rates against the API server.
- Escape demonstrations: show that policy would admit an escape-capable pod, or demonstrate escape only on the dedicated test node, and record the finding without accessing other workloads' data.
- Secrets handling: record the name and location of a secret that could be read, not its value. If a value is exposed, the owner rotates it and the report records the rotation.
- Stop conditions: pause on API server latency, node pressure, unexpected autoscaling, cost alerts, access to another tenant's or provider's data, or signs of a real intruder. Real compromise indicators go straight to the Kubernetes Cluster Compromise Playbook.
- Managed services: your share of the shared responsibility model is in scope; the provider's control plane hosts are not. Check the provider's testing policy before each engagement, as described in the Cloud Penetration Testing Guide.
Running the engagement
- Baseline: run a CIS benchmark review and export RBAC bindings, admission policies, network policies and the namespace list, and share them with testers.
- Scope and authorise: list clusters, namespaces, node pools, registries and cloud accounts in scope, the starting positions, dates, source addresses and named contacts, signed by the cluster and cloud owners. The Penetration Test Scoping Checklist covers the general items.
- Prepare: create test identities and namespaces, confirm audit logging is on and exported, and decide whether the SOC is told (announced) or a named contact confirms activity on request (unannounced).
- Execute in order of risk: external and configuration-level checks first, then assumed-breach positions, then node and escape scenarios last, so the riskiest work happens when the team knows the cluster best.
- Daily check-in: testers report critical findings immediately (for example, an anonymous path to secrets) rather than at the end.
- Close: delete test identities, namespaces and marker objects, rotate any exposed credential, and confirm cleanup in writing.
- Retest: after remediation, retest each critical and high finding against the same starting position.
Rollback: keep manifests and RBAC exports from before testing in version control so any test object or accidental change can be reverted, and have the platform team rehearse disabling every test identity in one action.
Evidence, reporting and measurement
Ask for a report that a platform engineer can act on without repeating the test. The How to Read a Penetration Test Report guide covers the general structure; for Kubernetes, each finding should include:
- The chain: starting identity, each permission or setting used, and the end impact (cluster-admin, node, cloud role, tenant data).
- The exact object: namespace, RoleBinding or ClusterRoleBinding, service account, pod spec field or policy name that enabled the step.
- The fix and where it lives: the manifest, Helm value or infrastructure-as-code module to change, so the fix survives the next deployment.
- Detection evidence: timestamps so the SOC can confirm whether audit logs and runtime tools saw each step. Use the Kubernetes Audit Log Detection Guide to turn missed steps into rules.
| Metric | What it shows |
|---|---|
| Steps from compromised pod to cluster-admin or node (and whether any path exists) | Depth of defence; the target is no path |
| Identities holding any RBAC escalation right outside the platform team | RBAC hygiene; should fall each test |
| Test steps detected by audit logging or runtime tools | Detection coverage, as a percentage of steps |
| Critical and high findings fixed and retested within agreed time | Remediation discipline |
| Repeat findings from the previous test | Whether fixes landed in code rather than by hand |
Track findings to closure with the Penetration Test Remediation Tracker Template.
Framework mapping
| Framework | Reference | How the test supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CA-8 Penetration Testing | Independent testing of the cluster as a system component |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning, CA-2 Control Assessments | Benchmark review and validation that controls work as described |
| NIST CSF 2.0 | ID.RA-01, ID.IM-02 | Vulnerabilities identified and validated; improvements identified from tests |
| NIST SP 800-115 | Technical Guide to Information Security Testing and Assessment | Planning, execution and analysis structure for the engagement |
| OWASP Kubernetes Top Ten 2025 | K01 to K10 | Coverage checklist for scope and report |
| CIS Kubernetes benchmarks | Generic and managed-service editions | Configuration baseline before testing |
Common failure patterns
- Testing only from outside: an external-only test of a well-fronted cluster reports little, while the pod-level assumed-breach view that matters most is never examined.
- A benchmark scan sold as a penetration test: a list of failed CIS items without chains leaves the team fixing low-impact settings first.
- Testers given cluster-admin "to save time": the test then proves nothing about escalation, and a powerful credential exists outside normal control.
- Fixes applied by hand with kubectl: the next deployment reverts them and the same findings reappear at retest.
- Cloud boundary left out of scope: the cluster looks contained, but a pod can reach the metadata endpoint and act as the node's cloud role.
- Audit logging off during the test: the SOC learns nothing and detection gaps stay hidden. The Kubernetes security checklist also expects audit logs to be protected from general access.
Practitioner checklist
- Run a CIS benchmark review first and share RBAC, admission and network policy exports with testers.
- Choose at least one assumed-breach starting position (compromised pod or developer identity) as well as an external view.
- Put RBAC escalation rights, service account tokens, escape paths, network segmentation and the cloud boundary explicitly in scope.
- Issue dedicated, labelled, expiring test identities bound to agreed namespaces, and delete them at close.
- Write Kubernetes-specific stop conditions and a marker-object rule into the rules of engagement.
- Confirm audit logging is on and exported before testing starts, and compare test steps with detections afterwards.
- Require each finding to name the exact object and the infrastructure-as-code location of the fix.
- Retest critical and high findings from the same starting position.
Standards and references
- Kubernetes: Role Based Access Control Good Practices
- Kubernetes: Security Checklist
- OWASP: Kubernetes Top Ten
- NSA and CISA: Kubernetes Hardening Guidance
- CIS: Kubernetes Benchmarks
- NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
- Microsoft: Threat Matrix for Kubernetes
- Kubernetes: Kubelet Authentication and Authorization
Related NHI Mgmt Group resources: Penetration Testing Guide · Cloud Penetration Testing Guide · Kubernetes Security Guide · Kubernetes NHI Security Guide · Penetration Testing Provider Buyer's Guide