HackBlue

Tools · Containers and Kubernetes security · 08 / 20

Running kube-bench: checking a cluster against the CIS Kubernetes Benchmark

Run kube-bench as a Job, read PASS, FAIL, WARN, and INFO results, and understand which checks apply to managed clusters.

9 min read · practice only with authorization

What kube-bench checks

The CIS Kubernetes Benchmark lists configuration recommendations for control-plane components, etcd, worker nodes, and policies. kube-bench from Aqua Security reads process flags and file permissions on the node where it runs and reports each check. Managed services have their own benchmark variants (EKS, AKS, GKE) because you cannot see or change their control planes.

Running it

The simplest way is the job manifest from the project repository, which mounts host paths read-only and prints results to the pod log. Use the job-master variant on a control-plane node and the standard job on workers, or the managed-service job for your provider.

Snippet
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl wait --for=condition=complete job/kube-bench --timeout=120s
kubectl logs job/kube-bench > kube-bench.txt
grep -E '^\[(FAIL|WARN)\]' kube-bench.txt | head -30

Lab: fix one failing check

On a kind cluster, run the master job and pick one FAIL such as the API server profiling flag or kubelet anonymous authentication. Each result has a remediation section naming the file and flag. Apply the change inside the kind node, wait for the static pod to restart, and run the job again to watch the check move to PASS. Record any check you decide not to fix and why.

Reading results

FAIL means an automated check did not match. WARN usually means a manual check that kube-bench cannot verify, such as reviewing RBAC. Treat the benchmark as a baseline, not proof of security: it says little about your workloads, images, or network policies.

Diagram

Result types

Each line in the report has one of these.

  • PASS

    Configuration matches the recommendation.

  • FAIL

    Automated check failed; remediation text says what to change.

  • WARN

    Manual check or check that could not be verified.

  • INFO

    Section headers and context.

Check yourself

1. Which standard does kube-bench test against?

2. What does WARN usually mean in kube-bench output?

3. You run EKS. Which kube-bench target should you use?