# kube-bench: running the CIS Kubernetes Benchmark against a live cluster > kube-bench is Aqua Security's Go tool that checks whether Kubernetes is deployed according to the CIS Kubernetes Benchmark. It runs as a binary, a container, or a cluster job, and the checks themselves live in YAML files rather than in code. **aquasecurity/kube-bench** — Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark - Repository: https://github.com/aquasecurity/kube-bench - Stars: 8,206 · Forks: 1,339 - Language: Go - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/aquasecurity-kube-bench ## What kube-bench checks, and who actually needs it kube-bench answers a narrow question: is this Kubernetes deployment configured the way the CIS Kubernetes Benchmark says it should be? It is not a runtime sensor and it does not inspect application containers. It reads the configuration of the control plane and the nodes, then reports each benchmark item as pass, fail or warn. The audience is therefore compliance and platform teams. If an auditor, a customer questionnaire or an internal hardening standard asks for CIS evidence, kube-bench is one of the few tools that maps directly onto that document. The README is explicit that the project "implements the CIS Kubernetes Benchmark as closely as possible", and that issues about the benchmark text itself belong with the CIS community rather than the repository. It is also useful before an upgrade. Running it against a staging control plane shows which flags and file permissions have drifted from the baseline, which is cheaper than discovering the drift during an audit. What it will not do is tell you whether a pod is behaving suspiciously, whether an image has a known CVE, or whether your RBAC lets one namespace read another's secrets beyond the specific items the benchmark covers. ## How the checks are structured: YAML under cfg/, Go for the engine The design decision that matters most is that the test content is data, not code. The README states that "tests are configured with YAML files, making this tool easy to update as test specifications evolve", and the repository layout backs that up: a cfg/ directory ships alongside the Go sources and is copied into the container image. The Go side is the engine. main.go and the cmd/ and check/ packages parse the YAML, decide which test set applies, execute each check, and format the result. The Dockerfile shows the build shape: a golang build stage compiles the binary via make build, and the runtime stage is Alpine with bash, findutils, jq, kubectl, openssl and procps installed. Those packages are not decoration. The comments in the Dockerfile explain that procps provides GNU ps for the -C, -o cmd and --no-headers flags, findutils provides GNU xargs, and openssl is used by the OpenShift tests. A check that shells out to ps or xargs will behave differently on a minimal image without them. The runtime image also copies entrypoint.sh and helper_scripts/check_files_owner_in_dir.sh, and sets the entrypoint to that script with a default command of install. That is why the container can be pointed at a node and asked to run the checks in place. Test selection is automatic. According to the README, kube-bench "will determine the test set to run based on the Kubernetes version running on the machine", with docs/running.md covering the details. The repository also carries provider-specific job manifests: job.yaml, job-master.yaml, job-node.yaml, job-eks.yaml, job-eks-asff.yaml, job-eks-stig.yaml, job-gke.yaml, job-aks.yaml, job-iks.yaml, job-ack.yaml and job-tkgi.yaml. The existence of that many variants is itself a signal: managed distributions differ enough in where they put files and how they run the control plane that a single generic job is not always sufficient. ## Installing kube-bench and getting a first report The README's quick start runs kube-bench as a Kubernetes job. The supplied job.yaml is applied to the cluster, and the results are read from the pod's logs. The README gives this sequence: ```bash $ kubectl apply -f job.yaml job.batch/kube-bench created $ kubectl get pods NAME READY STATUS RESTARTS AGE kube-bench-j76s9 0/1 ContainerCreating 0 3s # Wait for a few seconds for the job to complete $ kubectl get pods NAME READY STATUS RESTARTS AGE kube-bench-j76s9 0/1 Completed 0 11s ``` Once the pod reaches Completed, the report is in its logs: ```bash kubectl logs kube-bench-j76s9 [INFO] 1 Master Node Security Configuration [INFO] 1.1 API Server ... ``` That output is the numbered benchmark structure, with each item reported individually. The README warns that running inside a pod requires access to the host's PID namespace so the tool can check running processes, and access to host directories where config files live. If the job completes suspiciously fast with everything passing, check the manifest before trusting it: without that host access the checks that inspect processes and files cannot see anything to fail on. For other ways to run it, including as a standalone binary, the README points to docs/running.md. The repository also ships Dockerfile.ubi and Dockerfile.fips.ubi for UBI-based and FIPS-only builds, which matters in regulated environments where the base image is constrained. The README does not document a rollback procedure for the job, and it does not document how to uninstall the binary. ## The benchmark release is the clock you run on The most consequential limitation is stated plainly in the README: "There is not a one-to-one mapping between releases of Kubernetes and releases of the CIS benchmark." A Kubernetes upgrade does not imply a corresponding benchmark update, and the roadmap section says the project plans to add support for new benchmark releases while noting that "these are not released as frequently as Kubernetes releases". In practice this means a cluster running a recent Kubernetes version may be assessed against an older benchmark revision, and the coverage table in docs/platforms.md is the place to check the mapping rather than assuming. If your compliance requirement names a specific benchmark version, verify that kube-bench ships a test set for it before you build a process around the tool. The second constraint follows from the first. Because checks are YAML, adapting them is editing files rather than writing code, which is genuinely convenient. It also means a local fork of cfg/ is now something you maintain across every upstream release, and the diff between your copy and upstream is the thing you have to reconcile each time. Teams that customise heavily should treat that as an ongoing cost, not a one-time edit. Finally, kube-bench reports on configuration. A passing result is not a statement that the cluster is secure, only that the benchmark items it evaluated were satisfied at the time it ran. ## kube-bench compared with Trivy and kube-hunter The README itself points at Trivy. It notes that Trivy, described there as the all-in-one cloud native security scanner, can be deployed as a Kubernetes Operator, and that both the Trivy CLI and the Trivy Operator "support CIS Kubernetes Benchmark scanning among several other features". That is the real difference in approach: kube-bench is a single-purpose benchmark runner, while Trivy folds the same CIS scanning into a broader scanner that also covers other artifact types. If you already run the Trivy Operator, adding kube-bench as a second tool duplicates the CIS portion rather than extending coverage. kube-hunter, which appears in the related searches alongside kube-bench, is a different kind of tool. kube-bench reads configuration and compares it to a written standard; a penetration-testing tool probes the cluster from the outside to find what is actually reachable. A benchmark pass and a clean penetration test are not the same result, and neither implies the other. The same distinction applies to kubescape, which the search data also pairs with kube-bench: the comparison is worth making on the basis of what each tool inspects, not on which produces a longer report. The honest summary is that kube-bench is the tool to choose when the deliverable is CIS benchmark evidence and nothing else. When the deliverable is a general security posture, a scanner that includes CIS checks as one input is usually the better fit. ## Licence, maintenance and upgrade cost kube-bench is licensed under Apache-2.0, and the repository carries both a LICENSE and a NOTICE file. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, but it also requires that the NOTICE file be preserved in distributions and that modified files carry prominent change notices. If you fork cfg/ and redistribute the result, that obligation travels with the fork. This is a description of the licence text, not legal advice; get your own counsel for a redistribution question. The repository is not archived. The last push was on 2026-09-21, and the most recent release listed is v0.16.0 from 2026-08-05, preceded by v0.15.6 on 2026-06-01 and v0.15.5 on 2026-05-20. The cadence is real but modest, and it tracks the benchmark rather than Kubernetes, which is the point made in the roadmap section. Budget for the upgrade cost accordingly: each new benchmark release can add, remove or reword items, and a result that flipped from pass to fail after an upgrade may reflect a changed requirement rather than a changed cluster. Record the kube-bench version alongside every report so the two are not confused later. ## Conclusion Adopt kube-bench if you need to produce CIS Kubernetes Benchmark evidence for a cluster you control, and you accept that the benchmark release, not Kubernetes, sets the pace. Do not adopt it as a runtime threat detector or as a substitute for scanning workload images and manifests; that is a different job. Before rolling it out, verify which CIS benchmark version your Kubernetes release maps to in docs/platforms.md, confirm the job manifest grants the host access the checks need, and decide whether the CLI or the Trivy Operator path fits your reporting. ## FAQ ### How do I install kube-bench? The README's quick start applies the supplied job.yaml to a cluster with kubectl apply -f job.yaml and reads the results from the pod logs. The README points to docs/running.md for other methods, and the repository also provides Dockerfile.ubi and Dockerfile.fips.ubi for UBI and FIPS-only builds. ### What is kube-bench and what does it do? It checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark, as the README states. Tests are configured with YAML files, and by default the tool determines the test set from the Kubernetes version running on the machine. ### How do I use kube-bench? Apply job.yaml to run the checks as a job, wait for the pod to reach Completed, then run kubectl logs on that pod to read the report. The README notes that running inside a pod requires access to the host's PID namespace and to host directories holding config files. ### How does kube-bench compare with Trivy? The README states that Trivy is an all-in-one cloud native security scanner, deployable as a Kubernetes Operator, and that both the Trivy CLI and the Trivy Operator support CIS Kubernetes Benchmark scanning among other features. kube-bench is a single-purpose benchmark runner rather than a general scanner. ### How does kube-bench compare with kube-hunter? kube-bench reads cluster configuration and compares it against the written CIS Kubernetes Benchmark, reporting each item as pass, fail or warn. kube-hunter is not covered by the README, so the repository does not document a comparison; the two should be evaluated on what each one inspects rather than on their output length. ### What are the alternatives to kube-bench? The README points to Trivy and the Trivy Operator, both of which support CIS Kubernetes Benchmark scanning among other features. Beyond that, the repository does not list alternatives, so any other comparison has to be made on what each tool inspects. ## Sources - [aquasecurity/kube-bench on GitHub](https://github.com/aquasecurity/kube-bench) - [Issues](https://github.com/aquasecurity/kube-bench/issues) - [License: Apache-2.0](https://github.com/aquasecurity/kube-bench/blob/main/LICENSE) - [README](https://github.com/aquasecurity/kube-bench/blob/main/README.md) - [Releases](https://github.com/aquasecurity/kube-bench/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aquasecurity-kube-bench