Last updated: November 4, 2026.
Kubernetes penetration testing should verify what a compromised workload or authenticated principal can actually do. Configuration review is essential, but effective risk depends on RBAC aggregation, service-account tokens, admission controls, node access, network paths and cloud workload identities.
The scope must name the cluster, namespaces, node groups, control-plane ownership, cloud account and approved starting positions. Managed Kubernetes services divide responsibility between the provider and customer, so unsupported control-plane actions should remain out of scope.
For the assessment framework, consult Kubernetes RBAC documentation and map the relevant guidance to the actual environment and authorized scope.
Define starting positions and trust zones
A test from outside the cluster answers a different question from a test starting in a low-privilege pod. Include the identities and workloads that represent realistic compromise scenarios.
| Starting point | Primary question | エビデンス |
|---|---|---|
| External application user | Can an app flaw reach cluster credentials or internal services? | Application requests and workload identity |
| Low-privilege pod | Can the workload access secrets, API resources or other namespaces? | Token permissions, mounts and network results |
| Namespace operator | Can delegated administration affect other tenants or cluster controls? | RBAC rules and successful actions |
| CI/CD identity | Can build or deployment access modify higher-trust workloads? | Pipeline permissions and admission outcome |
Turn the scope into testable evidence
Define an authorized target, validate meaningful attack paths, and keep the evidence connected to remediation and retesting.
Validate RBAC and service-account behavior
Review roles, bindings, aggregation and impersonation, then use approved read-only or reversible requests to validate effective permissions. Check automounted tokens, projected tokens, workload identity and whether applications need the permissions they receive.
Test workload and network isolation
Evaluate pod security settings, privileged capabilities, host mounts, node access and admission policies. Confirm NetworkPolicy behavior with permitted and blocked connections; remember that effectiveness depends on the network plugin and complete policy design.
Handle secrets and evidence safely
Kubernetes Secrets are not automatically a complete secret-management solution. Avoid extracting real credentials when metadata, access proof or a synthetic secret demonstrates the problem. Record namespace, service account, API verb, resource and resulting access for reproducibility.
Turn the scope into testable evidence
Define an authorized target, validate meaningful attack paths, and keep the evidence connected to remediation and retesting.
Questions buyers should ask
- Which clusters, namespaces, cloud accounts and CI/CD identities are authorized?
- What starting positions should be assumed?
- Are network policies and admission controls actually enforced by the deployed components?
- Can findings be demonstrated without collecting production secrets?
結論
A Kubernetes pentest should show whether identity, workload and network boundaries survive a realistic foothold. Combine configuration review with controlled effective-permission checks and leave the platform team with namespace, principal and resource-specific remediation evidence.
Sources and standards
- Kubernetes RBAC documentation
- Kubernetes NetworkPolicy documentation
- Kubernetes Secrets documentation
Japanese 
English 
German 
French 
Spanish 
Portuguese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew