Kubernetes Penetration Testing

Introduction to Kubernetes Penetration Testing

Clusters change by the minute. Pods appear and vanish, teams share infrastructure, and one set of control-plane APIs governs everything. A single over-permissioned service account can turn a small foothold into cluster-wide access.

Adoption keeps growing. CNCF's 2025 survey found 82% of container users running Kubernetes in production. That figure measures adoption, not breach rates, but it shows how much now depends on getting cluster security right.

This guide is for security leaders, DevOps teams, platform engineers, and compliance stakeholders. It covers the attack surface, testing methodology, safety controls, reporting, and remediation priorities.

Key Takeaways

• Penetration testing validates real attack paths; it doesn't replace scanning or configuration review.
• Focus on the API plane, RBAC, secrets, privileged workloads, segmentation, images, and CI/CD.
• Combine external, authenticated, assumed-breach, and compromised-container perspectives.
• Expect a risk-ranked plan, proven impact, detection notes, and a retest.

What Is Kubernetes Penetration Testing?

Kubernetes penetration testing is an authorized adversarial assessment of your cluster and the systems around it. Testers examine the control plane, worker nodes, container runtime, workloads, network paths, identities, cloud integrations, registries, and deployment processes.

NIST describes penetration testing as assessors mimicking real-world attacks to find ways around security features.

How It Differs From Scanning

Scanners, CIS benchmark checks, and image assessments identify possible weaknesses. Human testers go further:

• Validate whether a weakness is actually exploitable
• Chain lower-risk issues into a serious path
• Measure blast radius from a single compromised pod
• Separate theoretical exposure from practical impact

DeepSeas takes the same stance with its penetration testing: manual validation and real attacker tradecraft to surface attack paths that automated testing often misses.

When to Test

• A new cluster or cloud migration
• Major architecture or CI/CD changes
• Customer, board, or compliance requirements
• After an incident or audit failure
• A significant jump in workload sensitivity

Frequency depends on your obligations. PCI DSS 4.0 calls for testing at least every 12 months and after significant changes. CMMC Level 3 requires annual or change-driven testing. HIPAA's evaluation provision does not require an annual penetration test. Follow whatever your regulator or contract specifies.

Kubernetes Attack Surface and Common Findings

Control Plane and Management Interfaces

Testers check the API server, etcd, kubelets, dashboards, metrics endpoints, and admission controllers for exposure, weak authentication, excessive permissions, and unsafe reachability.

Defaults matter, and they vary by version and distribution. Upstream, the API server listens on 6443, etcd on 2379/2380, and the kubelet's secure API on 10250.

The kubelet read-only port is documented as 10255 on the command line, but the configuration-file readOnlyPort defaults to 0 (disabled). A nonzero read-only port has no authentication or authorization. Always confirm what your distribution actually runs.

The 2018 Tesla incident shows the stakes: an unprotected Kubernetes console exposed cloud credentials and led to cryptomining.

Identity, RBAC, and Secrets

Common findings:

• Broad Roles and ClusterRoleBindings, including routine use of cluster-admin
• Service-account tokens mounted into pods that never call the API
• Weak OIDC or identity-provider integration
• Secrets readable through the API or environment variables
• Upstream Secrets stored unencrypted in etcd (base64 is not encryption)

Each one maps to escalation or lateral movement. A pod token that can read secrets cluster-wide, for example, becomes a path to cloud credentials. Permissions such as bind and escalate can also bypass Kubernetes' own escalation protections.

Workloads, Nodes, and Container Runtime

Look for:

• Privileged containers and root execution
• Excess Linux capabilities and hostPath mounts
• Exposed container runtime sockets
• Debugging pods left behind

Any of these can turn one compromised pod into node control, and node control into cluster control.

Runtime flaws count too. CVE-2024-21626 in runc (versions 1.0.0-rc93 through 1.1.11) allowed container escape via leaked file descriptors. It's a runtime advisory, not proof every cluster is affected, which is why testers verify versions rather than assume.

Network, Service Exposure, and Cloud Paths

Pods are non-isolated by default, and NetworkPolicies only work with a supporting network plugin. Testers examine:

• Ingress controllers, LoadBalancer, and NodePort exposure
• Missing default-deny policies and open east-west traffic
• DNS and service discovery
• Egress paths and cloud metadata access
• Links to managed cloud services

The ingress-nginx flaw CVE-2025-1974 (CVSS 9.8) showed how an admission controller reachable from the pod network could lead to takeover when combined with related bugs.

Supply Chain, CI/CD, and Add-Ons

These areas belong in scope:

• Registries, image provenance, and base images
• Helm charts, GitOps repositories, and Infrastructure as Code
• Build secrets and service meshes

Map findings to the OWASP Kubernetes Top Ten, CIS Kubernetes Benchmark controls, and MITRE ATT&CK for Containers so remediation owners and auditors share a vocabulary.

Kubernetes Penetration Testing Methodology

NIST SP 800-115 frames testing in four phases: planning, discovery, attack, and reporting. PTES adds threat modeling and post-exploitation. Both fit Kubernetes well.

Planning, Authorization, and Scope

Settle the rules of engagement before anyone touches a cluster:

• Written authorization and in-scope clusters, accounts, and test identities
• Production versus non-production boundaries
• Cloud-provider responsibilities and policies
• Sensitive workloads, permitted actions, and stop conditions
• Communication channels, rollback procedures, and evidence handling

Provider rules differ. AWS's pre-approved service list doesn't explicitly name EKS, and any testing involving command and control needs prior approval.

Azure requires no notification but prohibits DDoS testing. Google doesn't require contact for your own projects. Customer authorization never covers attacking provider infrastructure or other tenants.

Threat Modeling and Test Perspectives

Design cases for four actors:

1. An external attacker with no access
2. An authenticated cloud or Kubernetes user
3. An assumed-breach insider with internal network access
4. An attacker who has compromised a workload

Set objectives per actor: data access, privilege escalation, lateral movement, persistence, detection, and availability impact. Not every test needs to reach cluster-admin.

Reconnaissance and Enumeration

Start passive, then move to approved active checks:

• Passive sources: DNS, certificate transparency, public repositories, exposed documentation, and asset inventories
• Active checks: API endpoints, dashboards, registries, and ingress paths
• With access granted: namespaces, workloads, service accounts, roles, network policies, images, and versions

Controlled Validation and Attack-Path Analysis

Begin read-only and validate:

• Authentication and authorization
• Secrets access and workload isolation
• Runtime exposure, cloud pivots, and cross-namespace movement

Use synthetic targets where possible, avoid unnecessary data access, and document every link in the chain. NIST notes that real exploits against production carry high risk, so testers can stop before a damaging action.

Detection, Reporting, and Retesting

Check whether audit logging, cloud telemetry, runtime alerts, and SIEM integrations fired during test actions, and whether incident response escalated. Without an audit policy file, the API server's audit mechanism logs nothing.

Rate findings on likelihood, confidentiality, integrity, availability, and blast radius. FIRST's CVSS v4.0 can anchor severity, with environmental context layered on top.

Then retest fixes and record residual risk. A test is a point-in-time snapshot, so retesting is what proves the fix.

Tools, Evidence, and Reporting

Tools serve objectives; they don't substitute for expertise.

Objective	Typical tools
Authorized inspection	kubectl, approved API clients
Surface discovery	nmap, HTTP tools
Posture checks	kube-bench, Kubescape
Permission analysis	rbac-tool, KubiScan
Images and repositories	Trivy
Runtime visibility	Falco, Tetragon

Check maintenance before relying on a tool:

• kube-hunter last released 0.6.8 in 2022 and is no longer actively developed
• rbac-tool and KubiScan have no recent releases, so verify version compatibility
• Kube-bench, Kubescape, Trivy, Falco, and Tetragon all show 2026 releases

Evidence Requirements

• Sanitized request and response examples
• Affected resource identifiers, manifest, and RBAC excerpts
• Timestamps and screenshots where appropriate
• Attack-path diagrams and scope limitations
• Proof of impact without live credentials or unnecessary sensitive data

Structure the deliverable the way PTES recommends: an executive summary plus a technical report covering objectives, scope, attack path, impact, and remediation.

Turning Findings Into a Program

DeepSeas RED's offensive security team holds OSCP, OSCE, and OSWP certifications, and tester methods feed DeepSeas detection logic. Those findings can inform a broader, customized cyber defense or GRC program tied to policy, compliance, and architecture decisions. Agree scope for any Kubernetes engagement up front.

Remediation and Continuous Kubernetes Security

Restrict Exposed Interfaces First

Lock down anything publicly reachable: API servers, etcd, kubelets, dashboards, and registries. Apply network restrictions, TLS, strong authentication, and least privilege, and remove anonymous or legacy access.

Know who owns what. On EKS, AWS protects the control plane including etcd, while you own node configuration, network rules, and IAM. AKS and GKE split duties differently depending on configuration.

Strengthen Identity and Secret Management

• Scope RBAC narrowly and remove unneeded ClusterRoleBindings
• Set automountServiceAccountToken: false where pods don't need the API
• Prefer short-lived credentials and workload identity controls
• Use external secret management and encryption at rest
• Rewrite existing Secrets after enabling encryption; the configuration alone doesn't re-encrypt them
• Rotate anything exposed, and watch for unusual API or cloud-identity use

Harden Workloads, Nodes, and Network Boundaries

Pod Security Admission (stable since v1.25) replaces PodSecurityPolicy. In enforce mode it rejects violating pods; audit and warn only flag them.

• Apply the Restricted standard, non-root execution, and read-only filesystems
• Drop capabilities and set resource limits
• Control host mounts and remove runtime sockets
• Patch nodes promptly
• Use default-deny NetworkPolicies, explicit allowlists, and egress controls

Each step shrinks blast radius: a compromised pod then has fewer places to go.

Secure the Software Supply Chain and Delivery Pipeline

• Use minimal, signed images pinned by digest
• Generate SBOMs and scan dependencies and IaC
• Detect secrets in repositories and build systems
• Protect registries and enforce admission policies, for example with Sigstore's Policy Controller
• Separate build and runtime privileges
• Gate deployments so high-risk configurations are blocked

NIST SP 800-204D and SLSA offer useful guidance on provenance and pipeline trust.

Connect Findings to Monitoring, Compliance, and Retesting

Connect findings to audit logs, runtime detection, and cloud telemetry. Tune alerts, write incident-response playbooks, and assign a named owner to every finding with a retest date.

Map findings to CIS, NIST, ISO 27001, HIPAA, PCI DSS, or CMMC only where they apply to your organization.

DeepSeas GRC supports ISO 27001, SOC 2, CMMC, PCI DSS, and NIST with control mapping and evidence packaging. That is supporting expertise, not a guarantee of compliance.

Frequently Asked Questions

What is Kubernetes penetration testing?

It's an authorized adversarial assessment of clusters, workloads, identities, cloud integrations, and delivery systems. The goal is to validate practical attack paths and business impact.

How is Kubernetes penetration testing different from a vulnerability scan?

Scans automatically flag known vulnerabilities and misconfigurations. Penetration testing adds human validation, attack-path chaining, privilege analysis, and evidence of real impact.

What does a Kubernetes penetration test cover?

Based on the agreed scope: the API server, etcd, kubelets, workloads, nodes, RBAC, secrets, network policies, registries, CI/CD, cloud identities, and relevant add-ons.

Can Kubernetes penetration testing be performed safely in production?

Yes, with written authorization, scoped objectives, non-destructive techniques, stop conditions, and rollback plans. Run intrusive tests in non-production.

How often should Kubernetes clusters be penetration tested?

It depends on risk, regulatory or contractual duties, deployment velocity, and incident history. Full assessments, targeted tests after major changes, and continuous automated checks each play a different role.

Does Kubernetes penetration testing include cloud and CI/CD security?

It should whenever those areas can influence cluster compromise: cloud IAM, managed Kubernetes settings, registries, build systems, GitOps, IaC, image signing, secrets, and admission controls.