kube-bench and Kubescape Guide: Running Kubernetes Posture Scans Safely and Acting on Results

Kubernetes clusters drift from their hardening baseline every time a node image, flag or manifest changes, and most teams only find out during an audit or an incident. kube-bench and Kubescape are two open source scanners that defenders use to measure that drift: kube-bench checks node and control plane configuration against the CIS Kubernetes Benchmark, and Kubescape scans live clusters, manifests, Helm charts and images against frameworks such as NSA-CISA, MITRE ATT&CK and CIS. This guide explains what each tool checks, how to run it with the least access, how to turn findings into CI gates and tracked remediation, and how to handle exceptions without hiding risk. It is for platform engineers, cluster administrators and audit teams. Tools are listed alphabetically; order is not a ranking.

This is an independent guide from NHI Mgmt Group, based on the public documentation of kube-bench and Kubescape as of November 2026. It is not sponsored or reviewed by either project. Features change, so confirm settings against each project's current documentation.

Key takeaways

• They answer different questions. kube-bench reads files, flags and processes on a node to test CIS Benchmark items; Kubescape evaluates Kubernetes objects and manifests against control libraries, and can run continuously in-cluster.
• Match the benchmark to the platform. kube-bench maps Kubernetes versions to CIS Benchmark versions and has separate configs for EKS, GKE, AKS, OpenShift, k3s and RKE; on managed services only worker node checks are possible.
• Scanners are privileged identities. kube-bench needs the host PID namespace and host paths; Kubescape needs cluster-wide read. Run them as short-lived, read-only and isolated workloads.
• Exceptions need owners and expiry. Both tools support skipping or excepting checks; an undocumented exception turns a posture report into a false assurance.
• Posture is one layer. Pair scanning with admission control so that fixed issues cannot be reintroduced, and with runtime detection for what configuration cannot prevent.

What each tool checks

kube-bench is maintained by Aqua Security under the Apache 2.0 licence. It runs the checks documented in the CIS Kubernetes Benchmark, defined as YAML test files so they can be updated as benchmarks evolve. Kubescape was created by ARMO and is a CNCF incubating project; it describes itself as a Kubernetes security platform covering misconfiguration scanning, image vulnerability scanning using Grype, manifest auto-remediation, Validating Admission Policies and eBPF runtime monitoring through Inspektor Gadget.

Running kube-bench

kube-bench auto-detects the Kubernetes version and maps it to a benchmark: for example cis-1.12 covers Kubernetes 1.32 to 1.33 and cis-2.0 covers 1.34 to 1.35 in the project's platform table. It also detects which components run on the node so it only runs control plane checks where an API server is present. Override detection with --benchmark (for example --benchmark eks-1.5.0 or gke-1.6.0) or --version; specifying both is an error.

• Targets: kube-bench run --targets master,node,etcd,policies selects benchmark sections. GKE benchmarks add controlplane and managedservices targets.
• Selecting checks: --check runs individual check IDs, --group runs whole groups, --skip omits them. --scored and --unscored (both default true) select automated or manual CIS items.
• Managed clusters: the project states that master nodes of GKE, EKS, AKS and ACK cannot be inspected because you have no access to them; use the provider benchmark targets for worker nodes and rely on the provider's attestation for the control plane.
• Kubernetes Job: the supplied job.yaml sets hostPID: true and mounts host paths such as /etc/kubernetes, /var/lib/kubelet, /var/lib/etcd, /etc/systemd and /etc/cni/net.d read-only. To test control plane nodes, add a nodeSelector and tolerations for those nodes.
• CI exit codes: --exit-code sets the code returned when checks fail, so a pipeline that builds node images can fail on new FAIL results.
• Customising: mount your own config over /opt/kube-bench/cfg/, and mark a recommendation that does not apply as type: "skip" in the test YAML, which reports it as INFO rather than silently dropping it.

Running Kubescape

A bare kubescape scan evaluates the current kubeconfig context against all frameworks. kubescape scan framework nsa, framework mitre or a CIS framework name narrows it; kubescape scan control C-0057 runs a single control. The same command scans manifests, Helm charts (only dependencies already vendored in charts/) and Git repositories, which is how teams move checks left.

• Thresholds for CI: --compliance-threshold returns exit code 1 when the score is below the value (for framework and control scans and resource or control views); --severity-threshold fails on findings at or above a severity.
• Scope: --include-namespaces and --exclude-namespaces limit the scan. Excluding kube-system hides some of the most important findings, so do it only with a separate scan of system namespaces.
• Fixing: kubescape fix results.json changes manifest files, with --dry-run, --interactive and --output-dir options. For a cluster scan the patched manifests are printed and never applied automatically; route them through your normal GitOps change process.
• Pod Security Standards readiness: kubescape predict pss -n <namespace> --level Baseline or Restricted predicts which workloads would break under Pod Security Admission enforcement before you switch it on.
• Air-gapped use: kubescape download artifacts and --use-artifacts-from run scans offline, and an offline Grype database server supports image scanning without internet access.
• Report data: --hide pseudonymises sensitive metadata, and --encrypt with KUBESCAPE_MASTER_KEY (at least 16 characters) encrypts it in JSON reports. Use these when reports leave the platform team.

The in-cluster operator (kubescape-operator Helm chart) runs scheduled configuration and vulnerability scans through CronJobs (default schedule 0 0 * * *) when capabilities.configurationScan and capabilities.vulnerabilityScan are enabled, and stores results as Kubernetes resources such as workloadconfigurationscans.

Where identity fits

Both scanners are non-human identities with broad read access, and their findings are largely about other identities.

• kube-bench host access: host PID and host path mounts expose kubelet credentials and, on control plane nodes, etcd data and certificates. Run it as a Job in a dedicated namespace, delete the Job after collecting logs, and keep the mounts read-only as in the upstream job.yaml.
• Cloud permissions for findings export: kube-bench's AWS Security Hub integration needs securityhub:BatchImportFindings. The project offers either an IAM role for the pod's service account (IRSA) or the node group role; prefer the service account role, because a node role permission is available to every pod on the node. See the EKS Security Hardening Guide.
• Kubescape CLI credentials: the CLI uses whatever kubeconfig it is given. In CI, give it a dedicated service account bound to a read-only ClusterRole, never an administrator kubeconfig. See the Kubernetes RBAC Guide.
• Kubescape operator APIs: the chart value global.apiAuth.enabled (default true) requires a service account token and an RBAC grant, checked with TokenReview and SubjectAccessReview, on the in-cluster HTTP APIs of the scanner components. Leave it on. If you expose results to AI agents through the storage MCP option, each read is checked against the calling agent's own RBAC, so bind those roles per namespace.
• Acting on identity findings: C-0034, C-0035, C-0015 and C-0188 findings feed directly into service account clean-up. See How to find pods that automount service account tokens and How to audit Kubernetes cluster admin bindings.

How to implement

1. Inventory clusters and platforms: record each cluster's distribution and version so you choose the right kube-bench benchmark and Kubescape framework. Note which control plane items the provider owns.
2. Baseline in report-only mode: run kube-bench on one node of each node pool and a full Kubescape cluster scan. Store JSON results; do not fail anything yet.
3. Triage and record exceptions: for each failure decide fix, accept with an owner and review date, or not applicable. Encode them as kube-bench skip entries or Kubescape exception files (--exceptions), held in Git.
4. Fix the highest-impact items first: privileged and host-namespace workloads, anonymous kubelet or API access, cluster-admin bindings and automounted tokens, then file permissions and audit logging flags.
5. Shift left: scan manifests and Helm charts in pull requests with Kubescape and SARIF output; run kube-bench in node image pipelines with --exit-code. Start with warnings, then fail on new criticals only.
6. Prevent regression: enforce the fixed controls with Pod Security Admission or Validating Admission Policies, after predict pss shows nothing breaks. See the Kubernetes Admission Control Guide.
7. Schedule and report: run kube-bench after every node image change and at least monthly, and Kubescape continuously through the operator or nightly in CI. Roll back a gate by lowering the threshold or reverting the exception file, not by deleting the scan.

Decision guidance

• Self-managed control planes: kube-bench on control plane and etcd nodes is the most direct evidence for CIS sections on API server, controller manager, scheduler and etcd configuration.
• Managed Kubernetes: use the provider-specific kube-bench benchmark for worker nodes and Kubescape for workload and RBAC posture, since most of the remaining risk sits in what you deploy.
• Small teams: CI scans with fixed thresholds and a monthly kube-bench run are enough to start; skip the operator until someone owns the dashboards.
• Large estates: run the Kubescape operator per cluster, export results to a central store or Security Hub, and track exceptions as tickets with expiry.
• Audit evidence: keep dated JSON outputs and the exact benchmark version; auditors ask which version you measured against.

Detection and measurement

• Benchmark pass rate: percentage of scored CIS checks passing per node pool, trended per release.
• Critical workload findings: count of privileged, host-namespace or capability findings in production (target zero, every remaining one with an exception).
• Exception health: exceptions without owner or past expiry (target zero).
• Mean time to remediate: days from first detection to fix for high-severity controls.
• Shift-left coverage: share of deploying repositories with a manifest scan gate.
• Scan freshness: age of the latest successful scan per cluster; a failing scan Job is itself an alert.

Watch the scanners too: alert on any change to the scanner's ClusterRole, and on kube-bench Jobs left running beyond their expected duration.

Common failure patterns

• Scanning the wrong benchmark: running an older CIS version against a newer cluster produces passes and failures that do not match current guidance. Pin the benchmark explicitly.
• Treating managed control planes as passed: missing control plane results are not passes; document the provider's responsibility.
• Exceptions that never expire: a namespace-wide exception added during a migration quietly covers every later workload.
• Scanner with administrator rights: a CI kubeconfig with cluster-admin becomes a high-value secret in the pipeline.
• Findings with no regression guard: fixed manifests are reintroduced because nothing blocks them at admission.
• Ignoring exposed management surfaces: the Tesla Kubernetes Cryptojacking case began with an unauthenticated Kubernetes console that exposed cloud credentials, the kind of exposure regular posture review is meant to catch.

Framework mapping

Practitioner checklist

• Record each cluster's distribution and version and pin the matching benchmark or framework.
• Run kube-bench as a short-lived Job with read-only host mounts, then delete it.
• Give Kubescape a dedicated read-only service account; never an administrator kubeconfig.
• Export results with IRSA or workload identity rather than node-level cloud roles.
• Keep every skip and exception in Git with an owner, reason and review date.
• Gate pull requests on new critical manifest findings using SARIF or JUnit output.
• Run predict pss before enforcing Pod Security Admission levels.
• Enforce fixed controls at admission so they cannot regress.
• Keep the Kubescape operator API authentication setting enabled.
• Store dated JSON results as audit evidence.

Standards and references

• kube-bench: CIS Kubernetes Benchmark support and platforms
• kube-bench: Running kube-bench
• kube-bench: Flags and commands
• Kubescape: Project documentation and CLI reference
• Kubescape: Getting started, exceptions and PSS prediction
• Kubescape: Operator Helm chart reference
• Kubernetes: Pod Security Standards

Related NHI Mgmt Group resources: Kubernetes Security Guide · CIS Benchmarks Guide · Kubernetes Security Checklist · Kubernetes Admission Control Guide · Falco Runtime Security Guide