What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
- Current set of bundled benchmark profiles for managed and vendor distributions: verify against project documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
kube-bench evaluates the configuration of a Kubernetes node against the CIS Kubernetes Benchmark. The checks are not compiled in: they live in YAML files, one set per benchmark version and platform, where each control names a test and the command that proves it. Those tests inspect two things. The first is running process arguments, so a control requiring the API server to disable anonymous authentication becomes a test that reads the kube-apiserver command line and looks at a flag. The second is files on disk, so controls about kubeconfig and certificate permissions become ownership and mode checks under the Kubernetes configuration directory.
Because those inputs are local, kube-bench runs on the node, either as a host binary or as a Kubernetes Job that mounts the host filesystem and process namespace. It detects the cluster version and picks a matching benchmark, and carries separate profiles for managed services and vendor distributions where file layout and applicable controls differ. Output is per control: pass, fail, warn, or manual where a human has to decide, each with the benchmark's remediation text. JSON and JUnit output make it consumable by a pipeline.
Where it fits
This belongs to whoever owns cluster infrastructure, run as a scheduled Job across nodes or as a step when a cluster is provisioned. It is a good gate for a cluster build pipeline, since a fresh cluster should pass cleanly and any later failure is drift. It is not a developer tool and says nothing about the applications you deploy. You need host level access for results to be complete.
Strengths
- Maps directly onto a recognized benchmark, so results translate into audit evidence without a mapping exercise.
- Checks live in readable YAML, so skipping controls that do not apply or adding your own is straightforward.
- A single static binary with no backend or database runs in a Job, a CI step or on a host with equal ease.
Limitations
- On managed control planes you cannot inspect the master components, so much of the benchmark is unverifiable and reports as manual or skipped.
- It sees node and control plane configuration only. Workload manifests, RBAC bindings, network policy and admission configuration are outside its scope.
- A benchmark pass is a configuration baseline, not a security assessment, and treating the score as a goal produces exceptions rather than safety.
Who it suits
Useful for any team that has to demonstrate Kubernetes hardening against CIS, and for platform teams wanting automated drift detection on self managed clusters. Of limited value if you run entirely on managed control planes and expected broad coverage, and never sufficient alone, since it needs pairing with workload level policy tooling.
Used kube-bench? Recommend it under your own name and title.
Recommend this tool