Self-hosted Kubernetes security review

Why a self-hosted Kubernetes platform review matters to your audit, customers and launch

A self-hosted Kubernetes platform review tests the cluster your organization operates itself, whether on premises or in an air-gapped network, and it answers a question your auditor, customer or launch review will ask: can you show that the cluster is hardened? Unlike a managed cluster assessment in the cloud category, where the provider operates the control plane and publishes its own shared responsibility boundaries, this review covers the whole stack you run. That includes the control plane, etcd, the nodes, the network, the add-ons and the way workloads are admitted and isolated, because no cloud provider is carrying any of that responsibility for you.

The weaknesses that matter most sit in places teams rarely check after the initial build. Control plane components and etcd may be reachable on networks they were never meant to reach, or their certificates and encryption settings may have drifted from the original design. Operators, ingress controllers and monitoring add-ons often run with broad cluster roles that were granted for convenience. Workloads may run privileged or with host namespaces because no admission policy stopped them. Each of these gaps can turn a single compromised pod into a cluster-wide problem, and an assessor will expect you to show how you prevent that, not just describe your intent.

Before you commission a review, confirm which evidence your auditor or customer will accept, such as a benchmark result against the CIS Kubernetes Benchmark, a mapping of Pod Security Standards enforcement, or a documented admission policy. Ask who owns each control in your organization and whether those owners can produce configuration exports, role bindings and version records on request. A review that starts from that evidence list is far more useful to the people who will read the report than a general penetration test of the cluster.

Which weakness categories a Kubernetes review looks for

This table maps each weakness category in a self-run cluster to what it looks like in this target, why it matters, and the CIS Kubernetes Benchmark or Pod Security Standards level that usually anchors the check. Read it as a checklist of what the review examines, then confirm the exact benchmark section numbers and version against the CIS Kubernetes Benchmark your assessor will use.

Weakness category	What it looks like in a self-run cluster	Why it matters and where it is anchored
Control plane and API server exposure	API server reachable from networks that do not need administrative access, or anonymous and overly broad access left enabled on the control plane endpoint	Compromise of the API server gives control over every workload. Anchored to the control plane sections of the CIS Kubernetes Benchmark.
etcd encryption and access	Cluster secrets stored in etcd without encryption at rest, or etcd peers and clients reachable beyond the control plane nodes	etcd holds the cluster state, including Secrets. Anchored to the etcd and encryption sections of the CIS Kubernetes Benchmark.
Certificate and secret handling	Long-lived or unrotated certificates, secrets copied into manifests or config repositories, and no clear owner for certificate renewal	Expired or leaked credentials create outages or silent access. Assessors expect a documented rotation process and evidence of it running.
RBAC and service accounts	Cluster-admin bindings granted to people or workloads that do not need them, and default service account tokens mounted into pods that never call the API	Excess permissions turn a single compromised pod into cluster-wide reach. Anchored to the RBAC and service account sections of the CIS Kubernetes Benchmark.
Operators and add-ons with excess privilege	Third-party operators, ingress controllers or monitoring agents running with cluster-wide write access, privileged containers or hostPath mounts	Add-ons often run with broader rights than the applications they serve, and they are updated less often. Each component should be reviewed as its own trust boundary.
Workload isolation under Pod Security Standards	Namespaces without a Pod Security Admission label, privileged pods in application namespaces, or Baseline workloads that would fail the Restricted level	The Privileged, Baseline and Restricted levels set the baseline for host access and privilege escalation. Namespaces should be labeled deliberately, with exceptions documented.
Network policy and ingress exposure	No default-deny network policy, services exposed through ingress without TLS standards, or pods able to reach the node network and internal management endpoints	Flat networks let one foothold reach every service. Confirm which network plugin enforces policy, since not every plugin does.
Node and runtime hardening	Nodes running unpatched operating systems, writable host paths, kubelet anonymous access, or container runtimes without restricted configuration	Node compromise bypasses namespace controls. Anchored to the worker node sections of the CIS Kubernetes Benchmark, which should be checked against the version your assessor uses.
Logging and audit trail	API server audit logging disabled or unreviewed, container logs not shipped off the node, and no alerting on RBAC or admission changes	Without audit records, an assessor cannot reconstruct who changed what. Confirm retention periods with your own policy, since no retention figure is set here.

What can be in scope for a self-hosted Kubernetes platform review

A Kubernetes review is only as useful as its boundaries. The decisions below set which clusters, components and access levels the review covers, and what it deliberately leaves to other owners. Agree each one in writing before testing starts so findings map to systems the client actually controls.

Clusters and environments

Name every cluster in the review: production, staging, development, disaster recovery and any on-premises or air-gapped sites. Production findings carry the most weight, but staging often mirrors production configuration and drifts from it in ways that matter. Confirm whether each cluster is reviewed as a live system or from exported configuration, and whether air-gapped clusters can be reached only from a jump host or a supplied configuration bundle. Record the Kubernetes version of each cluster, since hardening expectations differ between releases.

Control plane and node coverage

Decide whether the review covers the API server, controller manager, scheduler, etcd and the worker nodes, and at what depth. Control plane hardening and etcd encryption and access settings are often reviewed from configuration files and certificates rather than by active testing. Worker nodes need an agreed list, including the operating system build, kubelet settings and container runtime. Ask the provider how many nodes are sampled and how the sample is chosen if the cluster is large.

Add-on and operator inventory

Build a written inventory of every operator, controller, Helm chart and cluster add-on, such as ingress controllers, service meshes, certificate managers, monitoring agents and storage drivers. Each one runs with privileges and often holds cluster-wide permissions, so it belongs in scope or in an explicit exclusion. Include version, source registry and who maintains upgrades. Components installed outside the platform team's knowledge are a common finding, so the inventory should come from live cluster state, not only from the deployment repository.

Namespaces and tenants

List the namespaces, the teams that own them and whether any tenant shares a cluster with another. Multi-tenant clusters need the review to check namespace isolation, network policies, resource quotas and role bindings across tenant boundaries, which takes more effort than a single-team cluster. Agree which namespaces hold regulated or sensitive workloads and whether the review samples workloads inside them. Record any tenant that runs untrusted code, since that changes the risk model.

Ingress and external exposure

Define how traffic reaches the cluster: ingress controllers, load balancers, node ports, API server endpoints and any services published to the internet or partner networks. Confirm which endpoints are reachable from outside the client's internal network and whether the Kubernetes API is exposed beyond administrators. Agree whether external testing of these endpoints is in scope, and under what notice, because it may overlap with a separate infrastructure test.

Benchmark version and rules of engagement

Name the CIS Kubernetes Benchmark version used as the baseline. The current version is 2.1.0, and the written scope should say whether results are mapped to that version or to a different one the client's auditor requires. Set the rules of engagement too: read-only configuration review, supervised testing with named client roles and an agreed contact during testing, or broader testing with defined stop conditions. Specify what is explicitly out of scope, such as the underlying hypervisor, storage arrays and the data center network, and who owns those systems.

How the review runs, phase by phase, from scoping to retest

The sequence moves from a written scope to evidence-backed findings and a retest, so each phase produces an artifact the next phase depends on. Durations are set in the written scope and are not assumed here.

Agree scope and rules in writing
Before any work starts, DeployOpen and the client agree in writing which clusters, namespaces, operators, ingress paths and environments are in scope, which tests are permitted, and which are excluded, such as production control planes or shared nodes that other teams depend on. The agreement also names the client contacts, the change windows, the stop conditions for testing and the people authorized to approve testing that could affect availability. The output is a signed scope document that defines the boundaries every later phase must respect. Ask the provider to state how scope changes are raised and approved during the engagement.
Gather information and review architecture
The team collects the platform inventory: Kubernetes version and distribution, how the control plane and etcd are deployed and reachable, node operating systems, the container runtime, networking and CNI choices, installed operators and add-ons, Helm releases, and the identity provider and admission setup. Reviewers also map trust boundaries between tenants, namespaces and the management network, and document how images are sourced and updated in an air-gapped or on-premises environment. The output is an architecture summary and a list of questions the client must answer, which is reviewed with the client before configuration checks begin.
Check configuration against the CIS Kubernetes Benchmark
Using the CIS Kubernetes Benchmark, currently version 2.1.0, reviewers assess control plane components, etcd, worker nodes, kubelet settings, policies and the configuration of the API server, with access granted under the agreed method, such as read-only kubeconfigs, audit logs or exported configuration. Each benchmark recommendation is marked as passed, failed, not applicable or requiring a documented exception, with the evidence attached. The output is a benchmark results table tied to the cluster version and configuration captured at the time of review, so the client can reproduce the result.
Assess Pod Security Standards and workload controls
Reviewers examine how Pod Security Standards are applied through the built-in Pod Security Admission controller, including which namespaces run under the Privileged, Baseline or Restricted policy, which enforce, audit or warn modes are set, and where exemptions exist. They also review workload defaults such as service accounts, RBAC bindings, network policies, secrets handling and resource limits in representative namespaces. The output is a namespace-by-namespace view of enforced policy, with each exemption justified or flagged for remediation. Ask the client to confirm which workloads legitimately need elevated privileges before the review begins.
Test exposed interfaces and tenant boundaries
Targeted testing covers the interfaces that are reachable: the Kubernetes API endpoint, ingress controllers and their exposed routes, dashboards, operator web consoles, and the isolation between tenants or namespaces. Testing runs only within the limits written in the scope, such as which endpoints may be probed, whether any destructive action is excluded, and how testing is paused if a service degrades. Reviewers record what was attempted, what was observed and any unexpected behavior. The output is a test log linked to each scoped interface, which supports the findings and shows the client what was and was not exercised.
Validate findings and rate impact
Each candidate finding is reproduced or confirmed through a second review, and checked against the client's actual configuration to rule out false positives and to confirm the setting is not compensated elsewhere, such as by a network policy or an admission rule. Reviewers rate impact and priority with the client, since the remediation timeline is set by each finding's impact and priority, as CIS Controls v8.1 Safeguard 18.3 describes. The output is a validated finding list with evidence, affected components, and a severity rationale the client can take to its own risk process.
Deliver the report and walk through findings
The written report covers scope and method, benchmark and Pod Security Standards results, validated findings with evidence and recommended fixes, items excluded from scope, and open questions. DeployOpen walks the client's platform and security teams through the findings and agrees which items need remediation owners and dates. The report does not constitute an audit opinion or certification; if the client needs evidence for an assessor, the report is one input the assessor may weigh. The output is the final report and an agreed remediation plan.
Retest after remediation
Once the client reports that fixes are in place, reviewers retest the findings in the agreed scope and record whether each is resolved, partially resolved or still open, with new evidence. Retesting also checks that remediation did not introduce a new exposure, such as a loosened admission rule or an exception added to avoid a failing control. Whether retesting is included, and how many rounds it covers, is stated in the written scope. The output is a retest summary that closes out each finding against the original report.

How testing differs for on-premises and air-gapped clusters

A connected on-premises cluster sits in your data center but can still reach external package repositories, vulnerability feeds and image registries. Testing looks much like a cluster in a cloud account, except that you own the hypervisor, network segmentation and physical access controls, so those layers belong in scope too. Access usually runs through a jump host or bastion inside the management network, and the tester works from there with agreed accounts.

Access path: Confirm which jump hosts, VPN segments and bastion accounts the testers will use, and whether source addresses are allowlisted for the API server.
Scanner updates: Connected scanners can refresh rule and vulnerability data at test time, so ask whether updates will be pulled during the engagement and from where.
Local evidence: Collect cluster version, API server flags, etcd peer and client TLS settings, and admission configuration directly from the nodes and manifests.
Registry review: Check whether the cluster pulls from public registries, and whether pull-through caches or mirrors are used and who controls them.
Add-ons: Pay attention to ingress controllers, the CNI plugin and any operators that call external endpoints for updates or telemetry.

Before scoping, confirm the real network path from the testers to each control plane node and which outbound destinations the cluster is permitted to reach.

What drives the cost and length of a Kubernetes platform review

This table compares the factors that change the effort behind a self-hosted Kubernetes review, who carries each cost, and whether it is paid once or recurs. Read it before requesting a quote so the written scope names the clusters, add-ons, tenants and access constraints that set the price and timeline. No figures are given here because the final effort depends on the agreed scope.

Cost driver	Why it changes effort and who pays	One-time or recurring, and what to ask for in a quote
Number of clusters and nodes	Each cluster needs its own control plane, etcd, kubelet and node configuration review. Sampling more nodes adds collection and analysis time for the tester and more evidence handling for the client's platform team.	Mostly one-time for the assessment. Ask the provider to list every cluster and node pool in scope and how sampling is chosen.
Operators and add-ons	Ingress controllers, service meshes, CNI plugins, admission webhooks and custom operators each carry their own permissions, CRDs and update paths. Reviewing each one against its own documentation takes more time than the core cluster alone.	One-time for the review, with later effort if add-ons are upgraded. Ask for a named inventory with versions and whether each component is in scope.
Namespaces and tenant roles	Every namespace, RBAC binding and service account must be checked for least privilege, and multi-tenant setups need tests that one tenant cannot reach another. Role count is often the largest variable on shared clusters.	One-time for the review. Ask how roles will be sampled and whether tenant isolation tests are included or optional.
Depth: configuration review versus tested attack paths	A configuration review compares settings with Pod Security Standards, the CIS Kubernetes Benchmark and the platform's own guidance. Testing attack paths, such as privilege escalation between workloads, takes additional planning and testing time and needs written rules of engagement.	One-time per engagement. Ask whether the quote covers configuration review only, attack path testing, or both, and which cluster environments are used for testing.
Air-gapped access logistics	Air-gapped or on-premises networks often require client-supplied jump hosts, approved tooling transfers, offline evidence collection and staff escorts. The tester and client both carry coordination effort that does not appear in an internet-connected test.	One-time setup per engagement, with possible repeat effort for retests. Ask who provisions access, how tools and evidence cross the boundary, and which hours are allowed.
Client platform team time	The client's Kubernetes administrators must provide cluster access, explain custom configuration and validate findings before they are final. This time is paid internally, but a quote should state what the provider expects from it.	One-time for the review. Ask for a list of client contacts and the review sessions the scope assumes.
Remediation support	Help with fixing findings, such as rewriting admission policies or tightening RBAC, is separate from the test itself. Support is billed as additional effort unless the written scope includes it.	Can be one-time or recurring if the client wants ongoing guidance. Ask whether remediation advice, pairing sessions or fix verification are included.
Retest	A retest checks that agreed findings have been fixed. Its effort depends on how many findings are retested and whether the cluster changed in ways that need a new baseline.	Usually a separate, later effort. Ask what the retest window is, how many findings it covers and whether it needs a new written scope.

Which frameworks ask for Kubernetes testing and what they expect

Few frameworks name Kubernetes directly, but many ask for evidence that a self-run container platform has been tested and that its findings are fixed. The most direct hooks are CIS Controls v8.1, which many regulated organizations use as a baseline. Safeguard 16.13 asks for application penetration testing, and Safeguard 18.3 asks that penetration test findings be remediated within a timeline set by each finding's impact and priority. A Kubernetes platform review does not replace application testing of the workloads running on the cluster, but it covers the layer that customers and auditors increasingly ask about: the control plane, etcd, admission settings, ingress and the add-ons that sit on top. Those results can be cited as part of the testing evidence for the platform, provided the scope and method are documented.

Customer security reviews and insurers often ask a narrower question: can you show how the cluster is configured against a recognized benchmark, and how quickly you fix what the review finds? For this topic, that means producing a mapping from the CIS Kubernetes Benchmark, currently at version 2.1.0, to your actual control plane and node settings, and showing which Pod Security Standards level (Privileged, Baseline or Restricted, enforced by Pod Security Admission) applies to each namespace. Ask your customer or insurer whether they expect a full benchmark run, a sample of namespaces, or a signed statement of configuration. Write the remediation timeline into your own policy before the review starts, so that the Safeguard 18.3 expectation can be shown against real dates.

Be clear about who produces what. DeployOpen prepares systems, controls and evidence for compliance assessments, and runs security testing, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions. Before commissioning the review, confirm with your auditor which evidence form they accept (for example, test reports, configuration exports, remediation records or a control mapping), whether they require a specific tester or methodology, and how far back the evidence must be current. Those answers should shape the written scope and the report format, not follow after the work is done.

What you receive from a Kubernetes review and whether it satisfies an auditor

A Kubernetes review produces evidence that your team can use, but the value depends on how the deliverables map to the controls your auditor or customer cares about. The cards below cover what the report contains, how benchmark results are presented, what retesting proves, and where a summary letter stops.

Report structure and executive summary

The report opens with an executive summary for leadership, then sets out scope, method, and the cluster versions, namespaces, nodes, and add-ons covered. Each finding lists its severity rating, the affected component (such as the API server, etcd, an operator, or an ingress controller), and reproduction context described at a defensive level. Remediation guidance is written so your platform engineers can change configuration without re-running the review. Ask for a sample report before signing so you can judge the level of detail.

CIS Kubernetes Benchmark mapping

Each benchmark recommendation checked in the review is marked as passed, failed, or not applicable, with the evidence behind the result. The benchmark version used should be stated explicitly, and CIS currently lists version 2.1.0 for the Kubernetes Benchmark. Ask whether the results include items marked manual and how exceptions are recorded, because an auditor will ask how each deviation was accepted.

Configuration evidence and Pod Security Standards results

Configuration evidence records the actual state of the control plane flags, etcd encryption and TLS settings, RBAC bindings, admission configuration, and namespace labels for Pod Security Admission. Pod Security Standards results show which namespaces enforce Privileged, Baseline, or Restricted policy and which workloads would be blocked. Ask for the raw exports or command output that support each claim, so your auditor can trace a finding to the cluster state at the time of testing.

Retest results and closure status

After your team fixes findings, a retest confirms whether each issue is closed, partly closed, or still open, and records the cluster state used for the check. The retest report should state which findings were verified, which were accepted as risk with a named owner, and which remain open with a date. Confirm in advance whether retesting is included in the fixed fee or priced separately, and how many rounds are covered.

Summary letter for customers or auditors

A summary letter describes the work performed, the scope, the dates, and the high-level results. It does not state that your platform is compliant, and it does not replace an independent auditor's opinion or a certification. Before the work starts, confirm the acceptance criteria with your auditor or customer, including the wording they will accept, which findings must be closed, and whether they expect the full report or only a summary.

What your team prepares before a self-hosted Kubernetes review starts

The fastest way to shorten scoping is to hand over a current architecture overview and a cluster and node inventory before the first call. The overview should show control plane nodes, worker pools, etcd placement, the networks between them, and whether the cluster sits on premises or in an air-gapped segment. The inventory should list each node's Kubernetes version, operating system and role. Testers use these two documents to decide which control plane and node settings to review against the CIS Kubernetes Benchmark, and which findings can be checked from configuration files rather than live systems. Without them, the first days of a review are spent rebuilding the map instead of testing it. Also ask your team to list the installed operators and add-ons with exact versions, since outdated controllers, ingress components and certificate managers are a common source of findings that no single benchmark covers.

Next, prepare the RBAC and namespace layout, the ingress and certificate design, and the backup and etcd arrangements. The RBAC export should show which service accounts, groups and cluster roles have elevated rights, and how Pod Security Standards are enforced per namespace through the Pod Security Admission controller. The ingress and certificate notes should name the controller, the TLS termination points, and who issues and renews certificates. Backup documentation should state where etcd snapshots are stored, how they are encrypted, and when a restore was last rehearsed. Each of these lets the team focus on gaps rather than on discovering the design. Confirm with your platform lead which of these artifacts are current, because outdated diagrams can send testers toward systems you have already retired.

Finally, agree the operational side in writing before anyone touches the environment. Name technical contacts who can answer questions within the working day, and provide access accounts with agreed roles, such as read-only cluster viewing for configuration review and a separate account for any authenticated testing. Confirm change freeze windows so that testing does not coincide with releases, and confirm your change control and incident response procedures, including who the testers should call if a control triggers an alert or a node becomes unstable. Ask your provider to show how these steps will be written into the rules of engagement, so that the security operations team knows when activity is expected and does not open an unplanned incident.

What to check in a Kubernetes security testing provider before you sign

A Kubernetes review of a platform you run yourself depends on the tester understanding your control plane, your network boundaries and your release process. The cards below cover what to verify and what to request in writing before you commit to a provider.

Hands-on cluster experience

Ask for evidence that the testers have built, operated and broken self-managed clusters, not only run scanners against them. Look for experience with kubeadm-style control planes, etcd backup and restore, certificate rotation and upgrade paths. Ask which Kubernetes versions they have assessed recently and how they handled a cluster whose add-ons were older than the core. Generic web application experience does not transfer directly to cluster-level review.

On-premises and air-gapped experience

A provider used to cloud-managed clusters may not know how to work without public registries, cloud metadata services or managed identity. Ask how they would test a cluster with no outbound internet access, how they obtain tools and images inside the boundary, and how they handle evidence transfer out of a restricted network. Ask for examples of similar environments described in general terms, since client names are usually confidential.

Written method tied to benchmarks

Request the test plan before signing. It should map each review area to the CIS Kubernetes Benchmark and to the Pod Security Standards, and state which checks are automated, which are manual and how each result is judged. A method that only names a scanner, without explaining how findings are confirmed against your configuration, gives you little to compare across providers.

Rules of engagement and data handling

Agree in writing which clusters, namespaces, nodes and accounts are in scope, what tests are off limits (for example, anything that could disrupt etcd or production workloads), and who can authorize changes during the test. Also confirm where scan output, secrets found during review and cluster snapshots are stored, who can access them and when they are deleted. Treat any credential the testers collect as sensitive data from the first minute.

Named testers and their roles

Ask for the names or role titles of the people who will work on your cluster, what each one covers (control plane, workloads, network, supply chain) and who signs off the findings. Confirm whether the lead tester is the same person who writes the report. Check any certifications the provider claims against your own requirements and ask for proof of current status, since credential lists change and not every certification applies to cluster work.

Sample report and retest terms

Before you sign, request a redacted sample report. Check that each finding states the affected component, evidence, impact in your context, severity rationale and a remediation step your platform team can act on. Also agree in writing how findings are validated, whether a retest is included, how long after delivery it can be requested and whether the retest result is delivered in the same format. Confirm that the report is suitable for your auditor or customer review.

Questions buyers ask before commissioning a self-hosted Kubernetes review

What does a self-hosted Kubernetes review cost and what drives the price?

The price follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of clusters and nodes in scope, how many distributions and environments (on-premises, air-gapped, disaster recovery) are reviewed, how many operators and add-ons need assessment, whether the team needs live testing of cluster exposure or a configuration review only, and how much access and evidence the client can provide up front. Ask the provider to split the quote into the assessment, the written report, any live testing and any retest, and to state which items are one-time and which recur if you retain them for continuous testing. Ask what a retest costs before you sign.

How long does a Kubernetes platform review take?

Duration is set by the scope, not by a standard number of days. The largest factors are the number of clusters, the depth of the control plane and etcd review, how many operators and add-ons are in use, whether the review runs in an air-gapped network with slower access, and how quickly the client grants credentials and answers questions about its change process. Ask for a timeline in the written scope that separates preparation, access setup, testing windows, reporting and the readout meeting. Confirm whether any production change freeze or maintenance window limits when testing can run.

What does our team have to provide before the review starts?

Expect to provide a clear list of clusters and environments in scope, cluster versions and distribution details, network diagrams and ingress paths, the current configuration of the API server, kubelet, etcd and admission controls, Helm charts or manifests, a list of installed operators and add-ons with their versions, and identity integration details. You will also need named contacts for change approval and incident handling, and read-only access to cluster configuration in a form agreed in advance. Confirm how sensitive data in manifests and secrets will be handled before sharing anything, and ask for the provider's data handling terms in writing.

Can our own staff run a Kubernetes security review instead?

Internal staff can run useful configuration checks against the CIS Kubernetes Benchmark and the Pod Security Standards, and many teams do this continuously with their own tooling. The gap usually lies in independence and adversarial thinking. Staff who built and operate the cluster tend to accept its design assumptions, and a review that the operating team also signs off is weaker evidence for an auditor or a customer. Internal checks also rarely cover how an attacker would chain a misconfigured add-on, an exposed ingress or a weak node boundary into a broader compromise. A common split is internal teams running regular benchmark checks while an external reviewer tests the design and the exposed paths.

How does a self-hosted Kubernetes review differ from a managed cluster assessment?

A self-hosted review covers the layers the client controls and operates itself: the control plane components, etcd, the node operating system, the container runtime, the network plugin, the ingress controller, storage, operators and add-ons, and the physical or private network boundary. A managed cluster assessment in the cloud category focuses on the provider's shared responsibility model, the provider's published testing rules, and the cloud account, identity and network configuration around a managed control plane. In a self-hosted engagement the reviewer can examine etcd encryption, API server flags and certificate management directly, which is usually out of reach in a managed service. Confirm which layers your scope includes so no part of the stack falls between two assessments.

Does a Kubernetes review satisfy a specific compliance framework?

A review does not certify compliance. Independent auditors and certification bodies decide whether a control is met, and DeployOpen prepares systems, controls and evidence for those assessments. A review can map findings to the control areas your framework asks for, such as the CIS Controls v8.1 penetration testing and remediation safeguards, which ask for application penetration testing and for findings to be fixed on a timeline set by impact and priority. Before commissioning, ask your auditor which evidence format they accept, whether they require a specific methodology, and whether they want the testing done by a provider independent of your operations team.

How is retesting priced and scheduled after findings are fixed?

Retesting usually covers only the findings you remediated, verified against the original scope, so it is typically smaller than the first review. Ask the provider to state in the written scope how many retest rounds are included, how verified fixes are recorded, and what happens to findings that are accepted as risk. Scheduling depends on when your change process can deploy fixes and on the reviewer's availability, so agree a retest window before the initial report is delivered. If you need ongoing checks between major reviews, ask whether a retainer covers continuous testing and how it is priced compared with one-off retests.

What happens to sensitive cluster data during and after the engagement?

Cluster data can include secrets, service account tokens, certificates, customer identifiers and internal network maps, so treat it as sensitive from the first day. Agree in writing where evidence is stored, who can access it, how long it is retained, how it is encrypted in transit and at rest, and how it is destroyed or returned at the end of the engagement. Ask whether the reviewer will work inside your environment or receive exported copies, and whether secrets are redacted from reports and screenshots. Because the review runs inside your own infrastructure, confirm which data, if any, leaves your network and under what approval.

How DeployOpen scopes, tests, reports and retests self-hosted Kubernetes platforms

DeployOpen runs Kubernetes platform reviews on clusters the client operates itself, on premises or in air-gapped networks, inside the client's own infrastructure. Each review follows a written scope, tests against the CIS Kubernetes Benchmark and Kubernetes Pod Security Standards, and ends with findings the client can take to remediation and retesting.

How we scope

The written scope names the clusters, control plane nodes, namespaces, operators and add-ons included in the review.
We confirm the Kubernetes version, distribution and whether the cluster is on premises or air-gapped before work starts.
Scope also records which CIS Benchmark version and Pod Security levels the client expects the review to measure against.

How we build

Testing covers control plane and etcd hardening, API server access, and how TLS is configured between cluster components.
We review operators, add-ons, ingress controllers and admission policies for privilege, exposure and default settings.
Findings are mapped to the relevant CIS Benchmark recommendations and Pod Security Standards so each item is traceable.

How we hand over

The report lists each finding with affected components, evidence, severity and a remediation path the platform team can act on.
Results are written so the client can share the benchmark mapping with internal auditors or customer security reviewers.
We state clearly which items were not tested, so the client knows what the review does not cover.

How we support

Fixed-scope engagements include a retest of agreed findings once the client has completed its remediation work.
Ongoing support, upgrades and continuous testing are available as a retainer for clusters that change frequently.
Ask us to confirm in the quote what retesting, re-scoping and support are included and what would be billed separately.