Kubernetes security assessment for EKS, AKS and GKE

Why teams commission a Kubernetes security assessment

A Kubernetes security assessment is a structured review of a managed cluster on EKS, AKS or GKE, measured against the CIS Kubernetes Benchmark, the Kubernetes Pod Security Standards and the NSA and CISA Kubernetes Hardening Guide. You receive a written report of what was tested, what was found, how each finding is rated and what to fix first, along with the evidence your auditor or customer can follow. Teams usually commission it because a compliance framework, a customer security questionnaire, a product launch or a cyber insurer asks for proof that the cluster is hardened, and a statement from the platform team is no longer enough. DeployOpen tests and reports on the cluster, but it does not issue audit reports, attestations or certifications. Those come from the independent auditor or certification body that your framework names.

The assessment targets five risk categories. The first is cluster misconfiguration, such as API server settings, control plane logging and node configuration that drift from the CIS benchmark version your provider's managed cluster benchmark covers. The second is excess privilege, where ClusterRoleBinding objects grant broad rights to service accounts, users or groups that never needed them. The third is workload escape, where pods run privileged, mount host paths or share host namespaces, which the Pod Security Standards Baseline and Restricted profiles are designed to block. The fourth is secrets exposure, covering Kubernetes Secrets readable by too many identities and credentials baked into images or manifests. The fifth is identity trust, where the link between pods and cloud identities, such as IAM Roles for Service Accounts on EKS or workload identity on AKS and GKE, grants more cloud access than the workload needs.

Before you commission the work, confirm three things with the provider in writing: which benchmark versions the review will map to, whether the Pod Security admission mode you run in production is the one under test, and whether the review covers the cloud identity and network layers around the cluster or only the Kubernetes API. Those answers decide whether the report will satisfy your reviewer. Ask for a findings list that maps each item to a benchmark control or hardening guide section, so the auditor can trace evidence without a second engagement.

What a Kubernetes security assessment can cover

A Kubernetes assessment is only as useful as its boundaries. The decisions below set which clusters, workloads and cloud accounts are examined, how far testing goes, and where the provider's responsibilities end and yours begin. Agree them in writing before any work starts.

Cluster and node pool selection

Decide which managed clusters are in scope and whether each node pool is covered separately. Node pools often differ in operating system image, instance profile, taints and autoscaling settings, so a hardened control plane can still sit on workers with weaker defaults. Ask the provider to confirm which benchmark version and cluster configuration each pool is measured against, and record any clusters that are excluded and why.

Namespaces and workload boundaries

Namespaces are the main isolation unit inside a shared cluster, so the assessment should list which ones hold production data, shared tooling or tenant workloads. Check whether Pod Security Admission is enforced per namespace, at which level, and whether exemptions exist. Namespace scope should be explicit, because a tenant namespace left out of scope can still reach in-scope services over the network.

Configuration review or in-cluster testing

Decide whether the work is a configuration review, which reads cluster and cloud settings without attacking them, or includes controlled testing from a workload or pod position. Testing from inside the cluster checks whether a compromised container could move laterally, reach the metadata service or read secrets. Each option has different access requirements, so agree the starting position, credentials and stop conditions in the rules of engagement.

Shared responsibility for the control plane

In EKS, AKS and GKE the provider operates and secures the managed control plane, while you configure access, node settings, workloads, network exposure and the cloud identities those workloads use. The assessment should separate findings you can fix from provider-side behavior you can only raise with the provider. Confirm the split against each provider's documentation rather than assuming it from the product name.

Cloud account and project alignment

Cluster scope must match the cloud account, subscription or project scope agreed with the provider. A cluster inside an in-scope account can depend on IAM roles, load balancers, container registries, key stores and logging in other accounts. Map those dependencies at scoping, and confirm that any testing touching cloud-level resources follows the provider's published testing rules for that service.

Rules of engagement and provider testing policies

Each provider publishes rules for customer testing, and they differ on approval, prohibited activity and reporting. AWS requires prior approval for command and control testing and bars denial of service, while Google Cloud asks only that tests affect your own projects. Record which provider policy governs the engagement, which activities are excluded, the testing window and who to contact if a test causes an alert or outage.

How the assessment runs, phase by phase

The sequence moves from a written scope to measured configuration findings, targeted testing of access and isolation, and a retest that shows which findings were closed. Each phase produces a record the client can check against the agreed scope and the reference frame.

Agree scope and the written statement of work
The client and DeployOpen confirm which clusters, managed control planes, node groups, namespaces, registries and cloud accounts are in scope, and which are excluded. They also agree the reference benchmark (CIS Kubernetes or the CIS EKS, AKS or GKE benchmark, depending on the platform), the Pod Security Standards level the workloads are expected to meet, and the testing boundaries set by the cloud provider's rules. The step closes when the statement of work is signed and lists the scope, deliverables and access model. For managed clusters, the client should confirm whether the provider's rules require prior approval for any testing that goes beyond configuration review, and the statement of work should record that answer.
Collect evidence with read-only access
Wherever possible, the assessor works through read-only roles that can list and describe cluster objects, RBAC bindings, namespace labels, network policies, admission configuration and cloud identity mappings. The client provides these roles and a documented list of what each one can read. Evidence is captured as configuration exports with timestamps and cluster version details, so the findings can be reproduced later. The step closes when the evidence set is complete, the access roles are recorded, and the client has confirmed that no production workload was changed during collection.
Run the benchmark-based configuration review
The assessor measures control plane settings, node configuration, kubelet arguments, audit logging and add-on configuration against the chosen CIS benchmark, and records each control as passed, failed, not applicable or requiring manual review. Managed services limit what a customer can change, so the review separates findings the client controls from settings the provider manages. The output is a control-by-control results sheet that names the benchmark version used. The client should confirm which benchmark version the auditor or customer expects, because the controls change between versions.
Measure workload isolation against Pod Security Standards
The assessor maps each namespace to its Pod Security Standards enforcement level, checks whether Pod Security Admission is enforcing, auditing or warning, and reviews workload specifications for privileged containers, host namespace sharing, host path mounts, capability grants, privilege escalation settings and missing security contexts. Findings are compared with the Privileged, Baseline and Restricted policies and with the hardening measures in the NSA and CISA Kubernetes Hardening Guide. The step closes with a namespace-level table showing the current level, the expected level and the gap for each workload group.
Test RBAC, network policy and secrets handling
Targeted testing examines who can act on which resources. The assessor reviews cluster role and role bindings for wildcard permissions, access to secrets, the ability to create workloads in privileged namespaces, and default service account token mounting. It checks whether network policies exist, whether default-deny posture applies, and whether ingress and egress paths match the intended design. Secrets handling is reviewed for encryption at rest, external secret stores, and exposure through environment variables or mounted files. Cloud identity integration, such as IAM role mapping to service accounts, is checked for over-broad grants. Testing stays within agreed boundaries, and the output is a list of confirmed access paths with the evidence that shows each one, reviewed with the client before reporting.
Assess exposure through workload entry points
Where the agreed scope includes it, the assessor examines the paths that reach workloads from outside the cluster, such as ingress controllers, load balancers, exposed services and any metadata endpoints reachable from pods. Server-side request forgery against cloud metadata addresses is a recognized weakness category for workloads that fetch remote URLs, so the assessor checks whether pods can reach instance metadata and whether the node or workload identity can be used from a pod. Any active testing is limited to the agreed targets and the provider's testing rules. The step closes with a list of reachable paths and the controls that limit them.
Deliver the report with severity ratings
The report presents each finding with a severity rating, the affected resources, the reference control or Pod Security Standards requirement it relates to, the evidence, and a recommended change the client's platform team can act on. It separates configuration findings from confirmed access paths and states what was not tested and why. Ratings follow a scale the client agrees during scoping. The client receives a findings register in a format that can feed a remediation tracker. The step closes when the readout has been held and the client has confirmed that every finding is understood, including which ones it accepts as risk.
Retest the remediated findings
After the client applies fixes, the assessor repeats the checks behind each closed finding and records whether the change resolved the issue, partly resolved it or introduced a new problem. Retesting is usually scoped in the original statement of work or agreed as a separate item, so the client should confirm the retest scope and its boundaries before the engagement starts. The retest produces an updated findings register with status per finding and the new evidence. Findings the client has accepted as risk stay open on the register with the acceptance recorded.

Weakness categories that cluster reviews surface

This table lists the weakness categories that most often appear in managed Kubernetes reviews, what each looks like in a cluster, and why it matters to the owner. Use it to check whether your own cluster has been reviewed against each category and to decide which areas to ask a provider to cover in scope.

Weakness category	What it looks like in the target	Why it matters
RBAC over-grant and cluster-admin sprawl	Service accounts or user groups bound to cluster-admin, wildcard verbs or resources, or roles that far exceed the workload's needs	A single compromised token can read secrets or change workloads across namespaces
Privileged or host-namespace workloads	Pods running privileged, sharing host network, PID or IPC namespaces, or mounting host paths, including namespaces without a Pod Security Standards level enforced	Workloads that do not meet the Baseline or Restricted level can often reach the node and its neighbors
Missing or permissive network policies	Namespaces with no ingress or egress policy, so any pod can reach any other pod, the API endpoints or external addresses	Flat networks let an attacker who gains one foothold move laterally and reach sensitive services
Secrets stored or exposed poorly	Credentials in environment variables, ConfigMaps or images, secrets readable by broad roles, and encryption at rest not confirmed for the secret store	Exposed secrets give direct access to databases, cloud APIs and other systems outside the cluster
Cloud identity integration over-grant	Workload identity or node instance roles with broader cloud permissions than the workloads need, or long-lived static keys used instead	Pods inherit cloud access, so a container compromise can become a cloud account compromise
Metadata service exposure through SSRF	Workloads that can reach the cloud instance metadata endpoint, and application endpoints that accept user-supplied URLs	Server-side request forgery against metadata endpoints can expose cloud credentials, a risk tracked as OWASP API7:2023
Control plane and audit logging gaps	Audit logging disabled or set to a minimal policy, logs not shipped off the cluster, or no alerting on privileged API calls	Without logs, the owner cannot reconstruct an incident or show an auditor that access is monitored
Exposed API server endpoints	A public API server endpoint without source restrictions, or private endpoint settings that differ from the documented design	The API server is the control point for the whole cluster, so unrestricted reachability widens the attack surface

How cloud identity links the cluster to the rest of the account

A managed cluster is never isolated from its cloud account. Pods reach cloud permissions through the identity they are given, either the node's instance or managed identity or a workload identity binding that maps a Kubernetes service account to a cloud role. If a workload can reach the instance metadata endpoint, such as 169.254.169.254, it may be able to obtain credentials for whatever the node or bound identity can do. The assessment therefore treats cluster RBAC and cloud IAM as one attack surface rather than two separate reviews.

We check the bindings first. For each cluster we map which service accounts are linked to cloud roles, whether those roles are scoped to the workloads that need them, and whether any node-level role carries permissions that no pod should inherit, such as broad storage, secret or registry access. On the metadata side we review whether the provider's metadata protections are enforced for node pools, including the hop limit settings on AWS EKS nodes and the equivalent controls on AKS and GKE, and whether network policies or host network settings let untrusted pods reach the endpoint at all. Server-side request forgery in an application is the common route to that endpoint, so we test whether a compromised pod could reach it through the application.

The output is a list of identity paths with a reason to trust or change each one. Confirm with your provider which metadata protections apply to your node pool version, since these settings vary by platform and release. For the cloud account itself, the AWS shared responsibility model places the configuration of your IAM roles, instance settings and cluster options on your side. Our AWS security assessment, Azure security assessment and Google Cloud security assessment pages cover the account-level IAM and logging review that completes this picture.

What drives the cost and duration of a cluster assessment

This table lists the factors that change how much work a Kubernetes assessment takes and what it costs to commission. Read each row as a question to answer in the scoping call, and use the recurring rows to plan retests and continuous review after the one-time assessment.

Driver	Why it changes cost or effort	How to keep it down or what to ask for
Number of clusters and node pools	Each cluster has its own API server configuration, add-ons, node images and admission settings to review, so effort grows with the cluster count.	List clusters by environment and tenancy model. Ask whether similar clusters can be sampled, and confirm how node pools are grouped.
Namespaces and workloads	Every namespace adds RBAC bindings, network policies and pod specs to check against the Pod Security Standards.	Scope by workload tier. Ask which namespaces hold payment, identity or regulated data and whether the rest can be covered by a sample.
Cloud accounts or projects linked to the cluster	Node IAM roles, workload identity bindings, load balancers and storage tied to the cluster sit in the cloud provider's control plane and must be reviewed alongside the cluster.	Count the AWS accounts, Azure subscriptions or Google Cloud projects in use. Ask whether cloud configuration review is included or quoted separately.
Identity integration complexity	Federation with an external identity provider, OIDC configuration, service account token handling and cloud workload identity each add paths to test.	Document the identity model before scoping. Confirm which integrations are in use and who owns them.
Testing from inside a workload	An assessment that starts from a pod, with credentials or a foothold assumed, needs explicit agreement on rules, tooling and cleanup, and adds time for the tester to work through what the workload can reach.	Decide whether the test is configuration review only or includes in-cluster testing. Ask for the written rules of engagement covering both.
Depth of benchmark coverage	A full pass against the CIS Kubernetes Benchmark and the CIS benchmark for the managed service covers many more checks than a targeted review of RBAC and network policy.	Name the benchmark versions and the checks in scope. Ask which items are automated and which need manual verification.
Evidence requirements from an auditor	Auditors may ask for specific artifacts, such as exported configuration, screenshots, change history or test logs, and each format adds collection and write-up work.	Share the auditor's evidence list before scoping. Ask how evidence is packaged and whether it maps to the framework controls in the report.
Retest scope	A retest of confirmed findings is smaller than a new assessment, but scope grows when fixes change architecture, add clusters or alter identity integration.	Ask for retest to be defined in the quote, including how many rounds are included and what happens if new clusters appear.
One-time versus recurring work	The initial assessment and final report are one-time costs. Retests, continuous configuration review and periodic reassessment after upgrades recur.	Ask the provider to separate the one-time quote from any retainer. Confirm how Kubernetes version upgrades and new clusters are handled.

What the client receives and whether it satisfies an auditor

The deliverable is a set of evidence that your auditor, customer or board can review against the benchmarks you have agreed to use. Each card below covers one part of the report, and the last card explains what the report does not claim, which is where most disputes start.

Executive summary and scope statement

The summary states which clusters, namespaces, node pools, cloud accounts and add-ons were tested, the test window, and the overall risk picture for leadership. The scope section lists what was excluded, such as application code, managed control plane internals or third-party operators. An auditor will check that the scope matches the systems in your compliance boundary, so confirm the cluster names and account IDs before the work starts.

Method and benchmark mapping

Each control is mapped to the matching recommendation in the CIS Kubernetes Benchmark, the CIS Amazon EKS, Azure AKS or Google GKE benchmark, the Pod Security Standards and the NSA and CISA hardening guide. For every mapped control the report records pass, fail, not applicable or manual review, with the reason. Ask which benchmark version was used, because the versions of CIS benchmarks change over time and your auditor may require a specific one.

Findings with severity and evidence

Each finding names the affected resource, the weakness category, the severity and the evidence that supports it, such as the manifest, role binding, policy or configuration output that was observed. Findings describe what is wrong and why it matters, without step-by-step exploitation detail. Ask how severity is assigned, whether it follows a published scale, and whether your risk owners can accept or challenge a rating before the final report is issued.

Remediation guidance and owners

Remediation entries give a specific corrective action for each finding, such as tightening a role binding, enforcing a Pod Security Standard on a namespace or restricting egress from a workload. Where the fix sits with the cloud provider rather than your team, the report says so, in line with the shared responsibility model. Ask for an owner and a priority on each item, so the list can be loaded into your ticketing system and tracked to closure.

Retest results

If remediation is included in the agreed scope, the retest section records each original finding as closed, partially closed or still open, with the evidence used to decide. Retest is usually a separate, smaller piece of work, so confirm in writing whether one retest round is included and how long you have to request it. An auditor reviewing a remediated finding will look for this section, not just the original list.

Limitations and what the report is not

The limitations statement records the testing period, the access the testers had, what was not sampled and any control that could only be assessed manually. The report is evidence for your auditor or customer. It is not an audit opinion, an attestation or a certification, and DeployOpen does not issue those. Agree the acceptance criteria with your assessor before the engagement starts, including the format, the benchmark version and whether they will accept this report as input.

How the assessment differs across EKS, AKS and GKE

Amazon EKS clusters are assessed against the CIS Amazon EKS Benchmark at version 2.0.0, alongside the CIS Kubernetes Benchmark at version 2.1.0 for the workload and node controls that both cover. AWS operates the managed control plane, so the review focuses on how your team configured it, how node groups are built, and how the cluster connects to your AWS account. Read the AWS shared responsibility model before scoping, so each finding has a clear owner. Confirm the testing rules before any active testing, because the AWS penetration testing policy lists specific services that may be tested without prior approval and that list does not name EKS directly.

Control plane configuration: endpoint access settings, control plane logging and secrets encryption, which the customer selects and checks against the EKS benchmark.
IAM integration: how pods obtain AWS credentials, whether service accounts map to narrowly scoped IAM roles, and whether node roles carry permissions that workloads do not need.
Node and add-on posture: node image currency, access from pods to the instance metadata service, and the configuration of networking and other cluster add-ons.
Network exposure: restrictions on the public endpoint, security groups around node groups, and the load balancers that services create.

Confirm in writing with AWS and your team which controls sit inside the customer boundary before testing begins.

What your team prepares before testing starts

Your team's preparation decides how much of the assessment time goes to testing rather than chasing access. Start by deciding how the assessor will see the cluster. For a configuration review, a read-only kubeconfig bound to a ClusterRole that can list and get workloads, RBAC objects, NetworkPolicies, namespaces and admission configuration is usually enough. Avoid handing out cluster-admin credentials for a review that does not need write access. Pair this with read roles in the cloud account that hosts the cluster, covering the control plane logging, node pool settings, cluster identity configuration and the IAM roles bound to Kubernetes service accounts (for example, IRSA on EKS, workload identity on AKS or GKE). Confirm which of these the assessor needs before the kickoff, because each one changes the access request.

Provide a current inventory of namespaces, workloads, service accounts and ingress paths, with the owning team for each. An export of workload manifests or a Helm release list, taken shortly before the start date, lets the assessor compare the Pod Security Standards labels on each namespace against what is actually deployed. Name one technical contact for the cluster, one for the cloud account and one for each application team that owns a namespace in scope, and agree how they will be reached during testing. Set a change freeze window for the cluster and its node pools, so that configuration reviewed in the assessment is the configuration being assessed. If in-cluster testing is included, agree in writing which test namespaces and test service accounts may be used, and which production namespaces are excluded.

Before testing starts, agree a backup and rollback plan for anything the assessor might touch, including etcd snapshots where your operating model supports them, exported manifests for any namespace in scope and a documented path to revert an admission or network policy change. Confirm with your cloud provider which testing activities are permitted against the managed control plane and the cluster's underlying resources. AWS, Microsoft and Google publish different rules for customer testing, and some activities, such as denial of service or request flooding, are prohibited under each provider's policy. Check the provider's current testing policy for your services, and ask your assessor to confirm in the statement of work which activities need prior approval. Keep a record of these decisions, since your auditor or customer will ask how the test stayed within the rules.

What to check before choosing a Kubernetes assessment provider

A Kubernetes assessment touches cluster configuration, workload isolation and cloud identity at once, so the provider you pick needs to cover all three. The checks below help you compare providers on experience, scope discipline, reporting and how they handle sensitive access before you sign.

Hands-on Kubernetes and cloud identity experience

Ask who will run the cluster review and whether they have worked hands-on with the managed control plane you use: EKS, AKS or GKE. Kubernetes findings often depend on how the cloud provider's identity layer maps to in-cluster RBAC, such as pod identity bindings or workload identity federation. A team that knows only generic container testing may miss those paths. Ask for named practitioners and the kinds of clusters they have reviewed, without client names.

Written scope and rules of engagement

Require a written scope that lists the clusters, namespaces, node pools, cloud accounts and any out-of-cluster services in play, along with the test window and the activities excluded. Confirm whether the provider will run intrusive checks, such as attempts to reach cloud metadata endpoints from pods, and how they will stop if production services degrade. Check that the cloud provider's testing policy applies to the services in scope, because some testing needs prior approval.

Familiarity with the named benchmarks

Confirm the provider can map findings to the CIS Kubernetes Benchmark, the CIS benchmark for your managed service, the Pod Security Standards and the NSA and CISA hardening guide. Ask which benchmark versions they use and how they handle a control they judge not applicable. A good answer explains the difference between automated benchmark checks and manual review of RBAC and network policy intent, and does not treat a scanner pass as a full assessment.

How findings are rated and evidenced

Ask how each finding is rated, what severity model is used and how the rating accounts for your environment, such as whether a privileged pod runs in a sensitive namespace. Each finding should include reproduction context, affected resources, the evidence captured and a remediation path a platform team can act on. Request a sample report structure before signing and check that it separates confirmed issues from observations.

Retest terms and remediation support

Clarify whether retesting is included, how many rounds it covers and how long after the original report it can be requested. Ask whether the provider verifies fixes in the live cluster or only reviews the configuration you send. Retest terms should state what counts as closed, who decides when a risk is accepted, and how accepted risks are recorded for your auditor or customer reviewers.

Handling of production access and secrets

Establish how the provider gets access, such as read-only kubeconfig with named roles, time-limited credentials or a jump environment you control. Ask how they avoid copying secrets, tokens or service account keys into reports and working files, how any sensitive material is destroyed and who approves elevated access. Confirm whether testing runs against a staging copy or production, since that decision changes the risk of each test you approve.

Kubernetes security assessment questions buyers ask

What does a Kubernetes security assessment cost?

The cost depends on how many clusters are in scope, how many node pools, namespaces and workloads they contain, whether the work includes only configuration review or also hands-on testing, and how many cloud accounts or projects the clusters connect to. The main cost is the consultant time needed to collect evidence, run checks against the CIS Kubernetes Benchmark and the cloud-specific CIS benchmarks, review RBAC and network policy, and write findings. Ask for a quote that lists each cluster, the benchmarks and guides used, whether testing includes exploitation attempts, the retest allowance and the report format. DeployOpen does not publish a price list, and a quote follows from the written scope. Recurring costs appear only if you add a retainer for continuous checks.

How long does a Kubernetes security assessment take?

Duration is set by the number of clusters, the size of their configurations, how many workloads and namespaces need review, and how quickly your team can provide access and answer questions. Time is also needed for remediation planning and the final report walkthrough, which fall outside the testing window. A cluster with mature GitOps configuration usually moves faster than one configured by hand, because the evidence is easier to collect. The written scope should state the start date, the testing window, the reporting date and the points where the client must respond. Ask the provider to show how these phases are sequenced for your environment before you commit.

What do we need to provide before the assessment starts?

You need to provide read-only or scoped access to the cluster and the cloud account that hosts it, a list of namespaces and workloads in scope, the cluster version and managed service settings, and documentation of the identity integration (for example, how cluster roles map to cloud IAM roles). Your team should also name a technical contact who can answer questions about workloads, and confirm change freezes and any production hours. For hands-on testing, agree the test accounts, the environments and the rules for stopping a test. Gaps in access or documentation usually lengthen the work and reduce the coverage of the report, so confirm the list against the written scope.

Can our internal team run a Kubernetes security assessment ourselves?

An internal team can run configuration checks against the CIS Kubernetes Benchmark, apply the Pod Security Standards using Pod Security Admission, and follow the NSA and CISA Kubernetes Hardening Guide. Open tools and cluster-level checks can find many common misconfigurations. What internal teams often find harder is independent judgment about their own design, confirming that RBAC and network policy do what they are meant to do, and testing the cloud identity link between the cluster and the provider account. An external review adds an independent view and written evidence. Many organizations combine both, with the internal team running continuous checks and an external assessment on a fixed schedule.

Will a Kubernetes security assessment satisfy our auditor?

An assessment produces evidence that an auditor may use, but it does not replace the auditor's work. DeployOpen prepares systems, controls and evidence for compliance assessments, and does not issue audit reports, attestations or certifications. Independent auditors and certification bodies decide whether controls meet a framework. Before commissioning the work, ask your auditor which controls they expect to see evidenced, whether they accept the CIS benchmarks and the NSA and CISA guide as reference points, and how they want findings and remediation tracked. Written scope that maps each check to the framework requirement makes the evidence easier for an auditor to review.

Do we need approval from our cloud provider before testing our cluster?

It depends on the provider and the type of testing. For AWS, the penetration testing policy lists services that customers may test without prior approval, including ECS and Fargate, and states that any testing that includes command and control (C2) needs prior approval. Microsoft's rules of engagement prohibit DDoS attacks and network-intensive fuzzing, and Google Cloud asks customers to follow its Acceptable Use Policy and Terms of Service and to affect only their own projects. Check whether your managed Kubernetes service and the connected services appear on the list for your provider, confirm the current policy text, and make sure the written scope excludes prohibited activity.

How does retesting work after findings are fixed?

Retesting checks whether the fixes you applied to the reported findings close the issues, and it is usually scoped as a separate, smaller piece of work. The written scope should state how many retest rounds are included, how fixes are evidenced (for example, configuration output or pipeline changes), which findings are in the retest, and the deadline for submitting fixes. Changes made after the retest window, or new workloads added later, fall outside the original report. For clusters that change often, a retainer for ongoing checks can replace periodic retests. Ask the provider to state in writing what a retest confirms and what it does not.

How DeployOpen scopes, tests, reports and retests Kubernetes clusters

DeployOpen approaches Kubernetes security assessment as a fixed-scope engagement agreed in writing before work starts. The work covers the cluster, its workloads and its cloud identity integration, and ends with documented findings and a retest path that fits your change schedule.

How we scope

Confirm which managed service (EKS, AKS or GKE) and which cluster versions are in the written scope
Record the namespaces, workloads, node pools and cloud accounts or projects that the assessment covers
Agree which CIS benchmark versions and Pod Security Standards levels will be used as the reference points
Confirm with your cloud provider any testing that falls outside its published rules for customer testing

How we build

Collect read-only configuration evidence and cluster settings from a reviewer account agreed with your team
Review RBAC bindings, service account tokens, admission policies and network policies against the agreed benchmarks
Test workload isolation and cloud identity paths in a controlled way, avoiding any disruption to production traffic
Map each weakness to a category, severity and the affected namespace or resource so owners can act on it

How we hand over

Deliver a written report with findings, evidence references, affected resources and recommended remediation steps
Include a benchmark coverage view showing which CIS controls passed, failed or were not applicable, with reasons
Walk through results with platform, security and compliance owners so that the evidence fits your audit or customer review
Confirm with your auditor or customer what format of evidence they accept before the report is finalized

How we support

Retest agreed findings after fixes are deployed and document which issues are closed, open or accepted
Ongoing support, upgrades and continuous testing are available as a retainer, based on the written scope
Ask us to confirm how retests, scope changes and new clusters are priced and scheduled before you sign
Keep the assessment current as Kubernetes versions and managed service defaults change over time