Kubernetes penetration testing vs CIS Benchmark scan

Kubernetes penetration testing or a CIS Benchmark scan: which one to commission first

A CIS Benchmark scan is the repeatable configuration check, a Kubernetes penetration test is the attacker-path check, and most platform teams need the scan first and the test once the baseline is in place. A platform team running self-hosted clusters has to show a security baseline before it can argue about anything more ambitious. NIST SP 800-115 describes configuration review as comparing settings against a security configuration guide or checklist, and it says automated checks are preferable where feasible because they are fast and repeatable. That makes the scan the right first step for proving that API server flags, kubelet settings, RBAC bindings and pod admission settings match the benchmark your team has chosen, and for catching drift after every upgrade. The scan alone is often enough for a small, stable cluster with a single trust boundary, no multi-tenancy, no sensitive workloads exposed to untrusted code, and no contractual or regulatory requirement for a human-led test. In that case, confirm that the cluster's Pod Security admission labels enforce the level you intend, that workloads do not run privileged, and that the scan runs on a schedule with findings tracked to closure. Be careful with the wording: the PCI SSC Penetration Testing Guidance says simply running an automated tool does not satisfy a penetration testing requirement. If an auditor or contract asks for a penetration test, a scan will not answer it. A tester is needed when clusters are shared between teams or customers, when workloads handle regulated or sensitive data, or when a manual test is required. A tester checks what the scan cannot: whether a compromised pod can reach the node, whether a service account token can be used to move laterally, and whether permissions combine into a path to cluster-admin. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so plan for both. Ask the provider to confirm in writing which cluster versions, cloud managed services and namespaces are in scope before testing begins.

How a CIS Benchmark scan and a Kubernetes penetration test compare

This table compares a configuration scan against the CIS Kubernetes Benchmark with a penetration test that tries to escape pods and move across the cluster. Read each row as a question: what the work answers, what access it needs, and what evidence it leaves behind. The main takeaway is that the scan shows whether settings match a checklist, while the penetration test shows whether those settings can be chained into a path to cluster-wide control.

Dimension	CIS Benchmark scan	Kubernetes penetration test
Goal	Check cluster and node settings against the CIS Kubernetes Benchmark	Find out whether an attacker can escape a pod, reach other workloads or gain cluster-admin rights
Question answered	Which configured settings deviate from the checklist?	Can a realistic attack path be chained from a foothold to the control plane or sensitive data?
Access needed	Read access to cluster configuration and node settings, typically with a scanner service account	An agreed starting foothold, such as a pod, a low-privilege service account or a developer kubeconfig, within written rules of engagement
Method	Configuration review: settings are compared with the benchmark's recommendations, and automated checks are preferred where feasible	Manual testing of container escape, RBAC abuse, service account token misuse, network policy gaps and node access, guided by the scope
Depth of findings	Shows each setting that departs from the checklist, but not whether settings combine into an exploitable path	Shows which weaknesses are reachable and what chain of steps leads to impact, with proof of the path
Repeatability	High: the same checks can run on a schedule or in a pipeline and produce comparable results over time	Lower: each test is a point-in-time exercise that depends on tester skill and the chosen starting point
Typical output	A list of benchmark checks with pass, fail or manual review status and remediation guidance	A narrative report with attack paths, evidence, severity and retest notes for each confirmed finding
Who performs it	Platform or security engineers can run it internally, and a reviewer confirms exceptions	An experienced tester with Kubernetes and container security skills, working under the agreed rules of engagement
Fit with frameworks	Maps to benchmark sections and supports configuration evidence; confirm with the assessor which control mapping they accept	Matches the penetration testing expectation in NIST SP 800-115 and the manual-testing emphasis in PCI SSC guidance; confirm the scope the assessor needs

What a CIS Benchmark scan checks in a cluster

A CIS Benchmark scan tests whether a cluster's live configuration matches each recommendation in the *CIS Kubernetes Benchmark*, which covers control plane components, worker nodes and policies. The scanner reads settings such as API server flags, kubelet arguments, file permissions on node components and the security context of workloads, then reports each recommendation as passed, failed or needing manual review. NIST SP 800-115 describes this activity as system configuration review: identifying weaknesses in security configuration controls by comparing settings with a security configuration guide or checklist. The same guidance prefers automated checks where feasible because they are fast and repeatable, which makes them practical to run on every change or on a fixed schedule.

Managed services use their own variants. The CIS lists the Amazon EKS, Azure AKS and Google GKE benchmarks at version 2.0.0, while the self-managed Kubernetes benchmark is at 2.1.0. Check which benchmark matches your control plane before you read the results, because some recommendations apply only to components you can configure. CIS Benchmarks are freely available as PDF for non-commercial use. If the scan runs inside a commercial product, a managed service or a client engagement, confirm the licensing terms with CIS before you assume the free copy covers that use. Ask your provider which benchmark version and profile its tool implements, since a scanner's rule set can lag the published document.

The limit is that a scan evaluates each setting in isolation. A cluster can pass every recommendation and still allow a path where a compromised pod reaches a service account with broad rights, or where a permitted workload mounts a host path that exposes credentials. The scan does not test whether an attacker can chain several acceptable settings into an escalation. Plan for that gap by pairing the scan with a tester who attempts pod escape and cluster-wide privilege escalation, and ask that tester to report which passing settings were still exploitable.

What each approach finds and misses

A benchmark scan and a penetration test answer different questions about the same cluster. The scan tells you whether individual settings match a checklist, while the test tells you whether an attacker can chain those settings, workload identities and reachable stores into a path to the cluster or its nodes.

Settings the scan catches

A CIS Benchmark run compares API server flags, kubelet settings, RBAC bindings and pod-level configuration against a checklist, and it does this quickly and the same way every time. It will flag permissive pod settings such as privileged containers or host namespace sharing, and it will flag broad cluster-admin bindings. Check that the benchmark version matches your distribution, since the CIS Kubernetes Benchmark is at version 2.1.0 and the managed-service benchmarks are separate documents.

Chained paths the scan misses

A scan evaluates each setting on its own, so it can pass a workload that has a benign-looking setting and a service account token with rights it should not have. Together those two facts may let a pod reach the Kubernetes API and create a more privileged workload. The scan does not follow that chain. Ask the tester to map which identities each workload holds and which of those identities can create, patch or exec into pods.

Escape and lateral movement the test finds

A penetration test attempts to break out of a container, reach the node filesystem, or use an over-privileged service account to read secrets in other namespaces. It can also show whether the node or a secret store is reachable from a compromised pod. These results depend on the tester's access and time, so a clean test means only that the tested paths did not work. Ask which starting identity, network position and namespaces were in scope.

Gaps in test scope

A penetration test does not check settings that were not tested or that fell outside the agreed scope, such as a namespace excluded for operational reasons or a control plane component the tester could not reach. Its findings are also only as broad as its starting access. Before testing, write down which clusters, namespaces, cloud accounts and identities are included, and treat any exclusion as a gap to cover with a configuration review.

Passive review versus exploitation

NIST SP 800-115 separates review techniques, which are passive and carry minimal risk, from penetration testing, which uses real exploits against live systems and carries higher risk. A cluster test can disrupt production workloads, so it needs written rules of engagement, and Appendix B of the guide provides a template for them. Agree on stop conditions, escalation contacts and whether exploitation may touch nodes that run other tenants.

Pod Security Standards and the NSA and CISA hardening guide: where they fit

The Kubernetes Pod Security Standards define three cumulative policies: Privileged, which is unrestricted; Baseline, which prevents known privilege escalations; and Restricted, which reflects current pod hardening best practice. Each policy builds on the one before it, so a workload that meets Restricted also meets Baseline. The built-in Pod Security Admission controller enforces these policies when pods are created or updated, which means the policy is a control on the admission path rather than a report written after the fact.

Scope of the check: The standards constrain pod specifications such as privileged containers, host namespaces, host paths and added capabilities.
Enforcement mode: Admission can enforce, audit or warn, so a namespace may log violations without blocking them. Confirm which mode each namespace uses.
What a scan sees: A scan can read namespace labels and confirm that enforcement is set.
What a test sees: A penetration test attempts a pod that should be rejected or contained, and reports whether the workload actually escapes.
Exemptions: Exempted namespaces or users bypass the policy, so ask for the exemption list during scoping.

Before accepting a Restricted label as proof of hardening, check that enforcement is not set to audit only and that no exemptions cover the workloads in scope.

How a Kubernetes penetration test tries to escape a pod and move across the cluster

A Kubernetes penetration test starts with a written scope that fixes the starting access, because the findings depend on it. Most engagements assume either a compromised pod (an assumed-breach position) or a standard tenant account with limited RBAC permissions. The rules of engagement should name the clusters and namespaces in scope, the cloud accounts and metadata endpoints allowed, the techniques that are off limits (such as denial of service), and who is notified if something breaks. Following PTES, the pre-engagement phase is where these decisions are recorded, and intelligence gathering then maps what the starting identity can see: its service account token, mounted secrets, reachable services and the roles bound to it. Confirm in writing that the test will run against a non-production cluster. If it must touch production, agree a planned window, a rollback path and a named contact who can stop the test.

From that position, the tester moves through vulnerability analysis and exploitation. Typical checks ask whether the pod runs privileged, shares host namespaces, mounts the host filesystem, or can reach the kubelet and other node services. They enumerate service accounts and their RoleBindings to see whether one identity can read secrets or create workloads across namespaces, and they test whether network policies actually stop lateral traffic. Where cloud metadata access is in scope, the tester checks whether a pod can reach the instance metadata service and obtain node credentials. Each step is validated, not inferred, and the tester records the path taken. Ask the provider to confirm which of these checks are permitted, and whether any test will create or modify workloads.

Post exploitation and reporting explain what the attacker could reach and what it would take to stop them, which a configuration scan does not show. A useful report traces each chain from starting access to the impact, cites the affected objects (for example a securityContext setting, a ClusterRoleBinding or a missing NetworkPolicy), and separates confirmed paths from configuration concerns. Ask for the report to state the access level used, the cluster version tested, and the cleanup performed. Then set the remediation order with the owners of each object, and retest the same paths after fixes so the detections and admission controls are shown to block them.

How to sequence a scan and a penetration test

This sequence moves a cluster from repeatable configuration checks to attacker-style testing, so each round of testing starts from a hardened baseline and the findings that remain are the ones a scan cannot reach. The order is a recommendation for most teams, not a fixed rule, and the right sequence depends on how the cluster is built and who owns it.

Inventory clusters and agree the target scope
The cluster owner lists every cluster in scope, including managed offerings, and records the Kubernetes version, the node operating system, the cloud or on-premises host, and the namespaces and workloads that matter most. The team agrees in writing which clusters, nodes and control plane components the tester may touch and which production constraints apply. The step is done when each cluster has a named owner and a signed scope that a tester and an auditor could both read.
Run the CIS Benchmark scan on each cluster
An operator runs an automated check against the CIS Kubernetes Benchmark version that matches the platform, and uses the managed-service benchmark where the cluster runs on Amazon EKS, Azure AKS or Google GKE. NIST SP 800-115 treats comparing settings with a configuration checklist as a review technique and favors automation because it is fast and repeatable. The output is a list of failed controls with the affected component, which the team triages into fix now, accept with a documented reason, or not applicable.
Fix repeatable settings and document exceptions
Platform engineers correct the failed settings that are safe to change in code, such as API server flags, kubelet options, RBAC bindings and network policy defaults, and store the changes in version control so they survive rebuilds. Each accepted exception carries an owner, a reason and a review trigger. The step closes when a fresh scan shows only accepted exceptions, and the scan report and change records are kept as evidence.
Enforce Pod Security Standards at namespace level
The team labels namespaces to enforce the Baseline policy first, then moves workloads toward the Restricted policy, using the built-in Pod Security Admission controller. Workloads that need privileges are identified and either refactored or placed in a namespace with a documented exception. The step is done when admission rejects non-compliant pods in enforced namespaces and the team can list which namespaces run under Privileged, Baseline or Restricted and why.
Apply the NSA and CISA hardening guidance to gaps
Using the Kubernetes Hardening Guide that NSA and CISA published, the platform team checks areas a benchmark scan may not weigh heavily, such as network segmentation, secrets handling, logging and image provenance. Each recommendation is either implemented or recorded as a risk decision. The step is complete when the team can show which guidance items are in place, which are deferred, and who approved each deferral.
Have a tester attack the hardened configuration
An independent tester, under the written rules of engagement, attempts what a scan cannot judge: escaping from a pod, reaching node credentials, abusing service account tokens, moving between namespaces and escalating through overly broad roles. PTES and NIST SP 800-115 both expect a defined scope, a planned set of techniques and a report of what was exploited. The step is complete when the tester delivers a report that separates confirmed attack paths from configuration observations, with reproduction steps.
Retest, validate detections and monitor continuously
The team fixes the confirmed paths, has the tester retest them, and checks that the monitoring stack alerts on the techniques the tester used, as CIS Safeguard 18.4 asks. Benchmark scans and Pod Security Admission audit events are scheduled and routed to the same tracking system as penetration test findings. NIST SP 800-115 suggests interleaving regular scanning with periodic penetration testing, so the cycle repeats after cluster upgrades and significant workload changes. The step is done when retest evidence and detection results are on file and the next scan date is set.

What you receive from each approach

This table compares what each approach hands you at the end, from a configuration scan report to a penetration test report with attack narratives and retest results. Read it to judge whether the output answers the question your auditor, board or platform team is asking. The main takeaway: a scan report is a configuration snapshot, while a penetration test report is only as complete as the methodology and rules of engagement agreed before testing started.

Deliverable	CIS Benchmark scan	Kubernetes penetration test
Core output	Pass, fail and manual-review results for each recommendation in the benchmark version used	Narrative of attempted attack paths, such as pod escape, token theft or privilege escalation, with the steps taken and what succeeded
Mapping to identifiers	Each result tied to a CIS Kubernetes Benchmark recommendation ID, so items can be traced and re-checked	Findings tied to affected workloads, namespaces, nodes and identities, with CIS or other references added only where useful
Scope and rules of engagement	Usually a list of clusters, node pools and benchmark version, with read-only access described	Written rules of engagement covering targets, permitted techniques, time windows, stop conditions and emergency contacts
Evidence	Command output or configuration extracts per check, which can be reproduced by the team	Captured requests, tokens redacted, screenshots or logs showing each step, with enough detail for a developer to reproduce
Risk rating	Usually a severity or benchmark profile level per check, not a judgment about exploitability	Risk ratings that reflect demonstrated impact in the tested environment, with the rating method stated in the report
Remediation guidance	Recommended setting or remediation text per failed check, often specific enough for a platform engineer	Remediation tied to each attack path, which may include configuration changes, architecture changes and monitoring gaps
Rerun output	Repeatable: the same scan can be rerun after changes and compared with the earlier run	Retest only if agreed in writing; confirm whether retest is included, how many rounds apply and what counts as closed
Dependence on methodology	Fixed by the benchmark and tool version, so output is predictable across runs	Depends on the methodology agreed, such as the depth of cluster and cloud identity testing, so ask for it in the statement of work
What the report is not	A configuration snapshot at the time of the run, not proof that an attacker could not reach workloads	A point-in-time view of what the tester could reach within the agreed scope, not proof that no other path exists

What drives the cost and effort of each

A benchmark scan and a penetration test are paid for in different units: the scan scales with how many configurations you check, the penetration test scales with how much of the cluster an attacker is allowed to reach. The cards below cover the drivers on each side, which parts are one-time and which recur, and what to ask for in a quote. Every quote follows from the written scope.

Cluster count and control plane model

A benchmark scan is run per cluster, so the number of clusters, and how many of them are managed services such as Amazon EKS, Azure AKS or Google GKE versus self-managed control planes, sets the scan workload. Managed control planes remove some checks from your scope because the provider operates those components, which changes what the scan can and cannot report. Ask the provider which benchmark variant each cluster is mapped to and whether the scan covers worker nodes, the control plane or both.

Benchmark variants and mapping

Each cluster type can map to a different benchmark variant, and the version in use decides which settings are checked. Running a scan against a managed-service variant when the cluster is self-managed produces misleading results. Ask for the exact benchmark and version for each cluster in the quote, and whether the report maps findings to your own Pod Security Standards level, such as Baseline or Restricted, so that remediation is tracked against your policy.

Remediation and re-scan effort

Scan tooling is often cheap to run once, but the recurring cost sits in fixing settings such as privileged containers, host namespace sharing and overly broad RBAC bindings, then re-scanning to confirm the fix. Your platform team carries most of this work. Ask whether the provider includes remediation guidance, a re-scan after changes and a written list of exceptions for settings you accept as risk.

Tenant and namespace scope

Penetration test effort grows with the number of tenants, namespaces and workloads an attacker is meant to try to reach. A multi-tenant cluster where teams share nodes needs tests for pod escape, lateral movement across namespaces and service account abuse, which takes more time than a single-team cluster. Ask the provider to list the namespaces, workloads and cross-tenant boundaries that are in scope, and which are excluded.

Access level and production scope

A test starting from a standard pod, with credentials for one namespace, costs less to define than a test that begins with cluster-admin access or includes node-level attacks. Testing production clusters adds planning for change windows, monitoring coverage and rollback, and often a more restrictive rules of engagement. Ask whether the test runs against production, staging or a replica, and which accounts and tokens the testers will receive.

Rules of engagement, retests and reporting

Penetration test pricing is shaped by the rules of engagement, the number of retest rounds after fixes, and the depth of the report, which may need attack paths, evidence and remediation steps for each finding. These are typically one-time items per engagement, while a periodic retest or retainer recurs. NIST SP 800-115 provides a rules of engagement template in Appendix B that you can use to define those limits before the quote is agreed. Ask what the price includes for retests and whether attack paths are documented in the report.

Questions buyers ask about Kubernetes testing and CIS scans

Is a CIS scan enough for a regulated Kubernetes cluster?

On its own, usually not. A CIS Benchmark scan checks cluster settings against a published checklist, which is fast and repeatable, and NIST SP 800-115 says automated configuration checks are preferable where feasible. It does not show whether a tester who already has a foothold in a pod can escape to the node, reach other namespaces or pivot to cloud identities. Regulated teams usually pair the scan with a penetration test, and they confirm with their assessor which combination their framework expects. Ask the assessor to name the evidence they will accept before the scan is treated as sufficient.

Does a Kubernetes scan satisfy a penetration testing requirement?

Generally no. PCI SSC's penetration testing guidance describes penetration testing as essentially a manual process and says that simply running an automated tool does not satisfy the requirement. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for internal and external penetration tests at least annually, which is a separate activity from configuration checking. Confirm with your assessor whether they accept a Kubernetes-focused test as part of the penetration testing scope, and whether they expect the tester to validate the scan findings in a live cluster.

What does a Kubernetes penetration test need from our team?

Expect the test to need named access and a few decisions before work starts. Typical inputs include the cluster versions and managed service in use, a test account with agreed privileges (for example, a namespace user or a pod-level foothold), a list of production namespaces and workloads that must not be disrupted, and an agreed window for any destructive steps. Your team should also name a technical contact who can respond quickly if a finding affects a live service. Put these in the written scope and the rules of engagement so that escalation paths are clear. The exact access level is a scoping choice, so agree it in writing rather than assuming it.

Can we run the CIS scan ourselves, and what is the licensing position?

Often yes. CIS states that its Benchmarks are freely available in PDF for non-commercial use, and it publishes the CIS Kubernetes Benchmark at version 2.1.0 along with Amazon EKS, Azure AKS and Google GKE benchmarks at 2.0.0. Commercial use, including scanning tools built on the Benchmarks, may fall under different terms, so check the current CIS licensing terms and any tool vendor's license before you embed a scan in a paid service or a commercial product. Running the scan internally still costs staff time to interpret results, triage false positives and track remediation, and those costs recur with every cluster upgrade.

How often should a CIS scan and a Kubernetes pen test run?

Run the scan on a regular schedule and after material changes, because NIST SP 800-115 suggests regularly scheduled scanning interspersed with periodic penetration testing. Trigger an extra scan after cluster upgrades, new admission policies or significant changes to node pools. The penetration test is usually periodic and tied to a control or contract requirement, so the interval is set by your framework and your risk appetite. CIS Controls v8.1 Safeguard 18.5 sets an annual baseline for penetration tests, and your assessor may expect more frequent work for high-risk clusters. Confirm the exact interval with your auditor.

What changes for EKS, AKS or GKE clusters?

The control plane is managed by the provider, so some CIS checks apply to the provider's configuration and others stay with you. The CIS Amazon EKS, Azure AKS and Google GKE benchmarks cover the managed-specific settings, and each should be run against the matching version. Under the AWS shared responsibility model, AWS secures the cloud while the customer is responsible for configuration choices in the cloud, which applies to cluster settings, node operating systems and network rules. Penetration testing also has to respect each provider's testing policy, and cloud identities and IAM roles often become the most important part of the attack path, so scope them explicitly.

When do we need a retest after findings are fixed?

Retest when a finding that enabled privilege escalation or lateral movement has been changed, and when the change could affect the path the tester used. CIS Controls v8.1 Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques testers used, which makes a targeted retest useful. A configuration scan can confirm that a setting now matches the benchmark, but only a tester can confirm that the attack path is closed. Agree the retest scope, timeline and cost in the original written scope so that remediation does not stall while waiting for a quote.

How DeployOpen works on this

DeployOpen plans and runs Kubernetes security testing inside the client's own cloud accounts, data centers or air-gapped networks, so cluster access and findings stay under the client's control. Where a CIS Benchmark scan and a penetration test both fit the risk, we agree the scope for each in writing before work starts.

How we scope

Written scope names the clusters, namespaces, managed services and tenancy boundaries that are in and out of bounds.
We agree whether the work is a configuration check against CIS benchmarks or an attempt to escape pods and move across the cluster.
Confirm with your cloud provider which Kubernetes services and testing activities their policies permit before the scope is signed.

How we build

We set up test accounts, roles and namespaces that mirror the production RBAC model, with rules of engagement agreed in advance.
Automated benchmark checks run first, then manual testing of pod escape paths, service accounts and network policy gaps.
Where a test could disrupt workloads, we agree a staging replica or a planned window with your platform team first.

How we hand over

Deliverables include the agreed scope, the test log, reproducible steps for each finding and the affected cluster objects.
Each finding maps to the relevant CIS Benchmark check, Pod Security Standards policy or NSA and CISA hardening guide recommendation.
Remediation guidance is written so your engineers can fix settings, then re-run the same checks to confirm closure.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
A retainer can re-run benchmark scans after cluster upgrades, managed-service changes or new workload onboarding.
Ask for the support terms, response expectations and handover format in your written quote, since these are agreed per engagement.