Kubernetes Security Testing

What is Kubernetes penetration testing?

Kubernetes penetration testing is the assessment of a cluster, its API server, RBAC model, workloads and the nodes underneath, to find the weaknesses an attacker could use once they have a foothold and to establish how far that foothold would take them. The usual starting point is not a kernel exploit. It is a service account with more permission than it needs, a pod running privileged, or a namespace with no network policy at all.

That makes Kubernetes penetration testing a different exercise to container image scanning. Image scanning tells you what software is inside a container. Cluster testing tells you what that container can reach, what it can mount, whose token it carries, and what a compromise of it would mean for everything else running alongside it.

PentestOps runs Kubernetes penetration testing agentlessly. You supply a read-only kubeconfig, the platform verifies connectivity and detects the distribution, and the audit runs through the Kubernetes API. There is no agent and no DaemonSet.

• The API and RBAC layer: who and what can act on the cluster, covered by 83 Kubernetes API and RBAC checks.
• The workload layer: privileged pods, host namespace sharing, container capabilities, security context and image provenance.
• The network layer: whether network policy actually restricts pod-to-pod traffic or only exists on a diagram.
• The node layer: host hardening measured against the CIS Kubernetes Benchmark, wherever the runtime permits it.

Kubernetes auditing without another agent

Most Kubernetes security tooling asks you to run a privileged DaemonSet on every node. That means more RBAC to grant, more upgrade toil, and a bigger attack surface inside the very clusters you are trying to protect. For platform teams already stretched thin, another in-cluster agent is a real cost.

PentestOps takes the opposite approach. You supply a read-only kubeconfig, the platform verifies connectivity and detects the distribution before any scan runs, and the audit happens through the Kubernetes API. There is no agent, no DaemonSet, and nothing left running in the cluster afterwards.

Two layers of coverage

Kubernetes risk splits into two questions: is the cluster configured safely, and are the nodes it runs on hardened? PentestOps answers both with two distinct layers.

API posture review, on every cluster

The posture review runs over the kubeconfig and examines how the cluster is actually configured: RBAC bindings, workload security context, privileged and host-namespace pods, container capabilities, network policy coverage and image provenance. It includes 83 Kubernetes API and RBAC checks, so over-broad access is surfaced before an attacker finds it.

Node-level CIS Kubernetes Benchmark

Where host-level pods are permitted (self-managed, on-prem, GKE Standard, EKS node groups and AKS), PentestOps runs CIS Kubernetes Benchmark checks at node level as a short-lived Job inside the cluster. The Job is auto-cleaned when it completes: it does not persist, does not poll, and leaves nothing behind to patch or monitor.

Honest coverage on GKE Autopilot and EKS Fargate

Fully managed runtimes such as GKE Autopilot and EKS Fargate do not permit host-level pods, so any tool claiming to run node checks inside them deserves scepticism. PentestOps routes node and control-plane CIS checks through the cloud configuration audit of the hosting account instead, while the API posture review still runs over the kubeconfig. You get a truthful view of what can be assessed on each runtime, not silent gaps.

What read-only access the platform needs

Kubernetes penetration testing should never require cluster-admin. PentestOps audits through a customer-supplied kubeconfig bound to a read-only ClusterRole: get, list and watch on the resources the checks read, and nothing more. No create, no update, no patch, no delete, no exec, and no need for the contents of your Secrets.

The exact resource list depends on which checks you enable and what your distribution exposes, so the snippet below is illustrative rather than a copy-paste artefact. Treat it as a shape to review with your platform team, not as a supported manifest.

• Verbs. Only get, list and watch. The audit never creates, updates, deletes or execs into anything.
• Illustrative ClusterRole header. apiVersion: rbac.authorization.k8s.io/v1, kind: ClusterRole, metadata.name: pentestops-readonly, followed by a rules list of four entries.
• Rule 1. apiGroups: [""], resources: ["pods", "nodes", "namespaces", "services", "serviceaccounts"], verbs: ["get", "list", "watch"]
• Rule 2. apiGroups: ["apps"], resources: ["deployments", "daemonsets", "statefulsets"], verbs: ["get", "list", "watch"]
• Rule 3. apiGroups: ["rbac.authorization.k8s.io"], resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"], verbs: ["get", "list", "watch"]
• Rule 4. apiGroups: ["networking.k8s.io"], resources: ["networkpolicies"], verbs: ["get", "list", "watch"]
• Binding. Attach the ClusterRole to a dedicated service account with a ClusterRoleBinding, build the kubeconfig from that service account, and delete the binding whenever you want access revoked.

The one thing that runs inside the cluster

The optional node-level CIS Kubernetes Benchmark Job is the single exception, because host configuration cannot be read over the API. It is short-lived, auto-cleaned on completion, runs only where host-level pods are permitted, and runs only where your Rules of Engagement allow it.

Kubeconfig credentials are held in a dedicated secrets vault and injected at runtime, never committed to source.

How it works

Cluster posture is a dedicated phase of the PentestOps 7-phase methodology, sitting alongside cloud configuration review and feeding the same analysis pipeline.

• 1. Onboard. Add the cluster as a verified asset and supply a read-only kubeconfig. One click; each cluster is one asset.
• 2. Verify. The platform checks connectivity and detects the distribution before any scan runs.
• 3. Review. The API posture review audits RBAC, workload security context, network policy and image provenance.
• 4. Benchmark. Where host-level pods are permitted, a short-lived, auto-cleaned Job runs node-level CIS checks; on Autopilot and Fargate these route through the cloud audit.
• 5. Report. Findings are prioritised with business context and mapped to compliance frameworks, exported as PDF, CSV or JSON/API.

Coverage by distribution

The API posture review runs on every supported cluster. Node-level CIS coverage depends on whether the runtime permits host-level pods.

What the audit surfaces

The Kubernetes weaknesses that lead to real compromise are rarely exotic. They are configuration debt: access granted broadly to save time, workloads running with more privilege than they need, and network segmentation that exists on a diagram but not in the cluster.

Findings feed the same prioritisation and reporting pipeline as the rest of the platform, including AI risk scoring with business context and mapping to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. For hardening guidance, see our guide to Kubernetes security best practices.

• Over-broad RBAC: cluster-admin sprawl and risky role bindings.
• Workloads running privileged or sharing host namespaces.
• Containers granted dangerous capabilities they do not need.
• Missing network policy, leaving pod-to-pod traffic unrestricted.
• Image provenance gaps, such as images from unvetted sources.
• Node-level hardening drift against the CIS Kubernetes Benchmark.

Why PentestOps for Kubernetes

Clusters do not exist in isolation, and neither should Kubernetes penetration testing.

• Agentless: a read-only kubeconfig, no DaemonSet, and nothing to install, upgrade or uninstall.
• Honest managed-runtime handling: Autopilot and Fargate coverage is routed through the cloud audit, not faked or silently skipped.
• Context beyond the cluster: pair cluster audits with cloud penetration testing of the hosting account and web application testing of the services the cluster runs.
• Asset-wise pricing: each cluster is one asset, with scans unlimited within fair use.
• Australian-built and operated. The platform is hosted in Australia on infrastructure operated by Extranet Systems, and Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified.