Skip to content

kube-bench — K8s audit against the CIS Benchmark

Security · Kubernetes
Studied

Problem

The cluster is up, running, apps are being deployed. Nobody knows whether audit logging is on, whether --anonymous-auth is allowed, whether etcd is exposed, or how the kubelet is configured. Everyone opens the CIS Kubernetes Benchmark and loses heart at 100+ manual checks.

Solution

kube-bench from Aqua "is a tool that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark". Tests are configured with YAML files, so the tool is easy to update as the specification evolves. It runs as a Job inside the cluster, reads component configs on the nodes and reports pass/warn/fail for each item.

Example

One command on a managed cluster (EKS/GKE/AKS):

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
kubectl logs -f job/kube-bench

A fragment of a typical report:

[INFO] 4 Worker Node Security Configuration
[INFO] 4.1 Worker Node Configuration Files
[PASS] 4.1.1 Ensure kubelet service file permissions are 600 or more restrictive
[FAIL] 4.1.2 Ensure kubelet service file ownership is root:root
[WARN] 4.2.6 Ensure --protect-kernel-defaults is set to true

For self-managed clusters (kubeadm):

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench-master
spec:
  template:
    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:v0.9.3
          command: ["kube-bench", "run", "--targets=master"]
      restartPolicy: Never

In CI — a weekly run with the report sent to Slack:

kube-bench --outputfile report.json --json
jq '.Totals.total_fail' report.json   # total number of FAILs

When to use

  • Right after provisioning a cluster — a baseline check.
  • Monthly on live clusters — to catch configuration drift.
  • After any control-plane upgrade.

Source

How to apply it yourself

  1. Run kube-bench as a one-off Job on every cluster (dev/stage/prod).
  2. Triage the FAILs: what can be fixed right away (permissions, kubelet flags) and what needs discussion (enabling the audit log).
  3. Add a weekly Job + report storage in S3.
  4. When the FAIL count keeps going down after the second iteration — status Studied.