kube-bench

Most clusters are never checked against a hardening baseline at all.
They get stood up, they work, workloads land on them, and nobody ever
asks whether the API server flags, the kubelet configuration, the file
permissions on the control-plane certs, and the dozens of other
settings that decide how exposed the cluster is are actually sane.
kube-bench, from Aqua Security, answers that question mechanically.

What It Does

kube-bench runs the checks from the CIS Kubernetes Benchmark, the
industry-standard hardening baseline for Kubernetes, against your
cluster and reports each one as pass, fail, or warn. The benchmark
covers the parts of the cluster you configure and usually forget: API
server settings, controller and scheduler flags, etcd, kubelet
configuration, the file permissions and ownership on control-plane
files, and the authorization and admission settings that decide how
much a compromised component can do.

You run it either as a job inside the cluster, where it inspects the
running components from a pod, or as a binary directly on a node. It
detects your Kubernetes version and picks the matching benchmark, and
it has dedicated variants for the managed platforms, EKS, GKE, AKS,
where you do not control the control plane and the relevant checks are
different. The tests themselves are plain YAML, which is why the tool
keeps up as the benchmark evolves, and it can emit machine-readable
output for a security dashboard rather than just text for a human.

Why Run It

The value is that it turns "is our cluster hardened" from a vague worry
into a concrete list. Instead of hoping the defaults were fine, you get
a specific enumeration of every setting that falls short of the
baseline, each tied to the exact benchmark item and a remediation. It
takes minutes to run and it finds the boring, high-impact
misconfigurations that nobody notices because the cluster works anyway:
an over-permissive API server flag, a kubelet that allows anonymous
auth, cert files readable by too many, an admission control default
left off.

These are exactly the findings that matter and never announce
themselves. A cluster runs fine with anonymous kubelet auth enabled,
right up until someone finds it. kube-bench is the cheapest way to
catch that class of thing before an engagement or an incident does. If
you run one security tool against a cluster you never checked, this is
a strong candidate for the first one.

It also belongs in CI. Run it against your cluster or your node images
on a schedule, gate on the high-severity fails, and configuration drift
that would otherwise accumulate silently shows up as a failing check
instead of a surprise years later.

The Limit Worth Understanding

kube-bench checks the cluster's configuration against a benchmark. That
is its whole scope, and it is important to be clear about what sits
outside it.

It does not look at your workloads. A cluster can pass the CIS
benchmark cleanly and still run pods as root, mount the docker socket,
grant cluster-admin to a service account, or ship an image full of
CVEs. The benchmark is about how the cluster itself is configured, not
about whether the things you deployed onto it are safe. Your RBAC
design, your secret handling, your pod security, your image hygiene are
all separate problems with separate tools.

So a green kube-bench run means the cluster's own configuration matches
the hardening baseline. It does not mean the cluster is secure, and
reading it as the latter is the usual mistake. It is one layer, the
infrastructure-configuration layer, scored well. The workload layer,
the identity layer, and the supply-chain layer each need their own
scoring, and a clean kube-bench result says nothing about any of them.

The Takeaway

kube-bench scores your cluster's configuration against the CIS
Kubernetes Benchmark in a single job and hands you a specific,
remediation-tagged list of where it falls short. Every cluster should
be run through it at least once, and ideally on a schedule so drift
surfaces as a failed check. Just remember what it covers: the cluster's
own hardening, not your workloads, your RBAC, or your images. Fix what
it finds, then go score the layers it does not touch.