kube-bench

Home

CIS Benchmarking with kube-bench

kube-bench is a tool from Aqua Security that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.

Project Repository: https://github.com/aquasecurity/kube-bench

1. Overview

kube-bench is typically run as a Job within your Kubernetes cluster. The Job manifest defines necessary volume mounts to allow kube-bench to inspect host configurations and Kubernetes component settings. The results indicate whether your setup passes or fails specific CIS benchmark recommendations.

You can obtain the example YAML files (like job.yaml, job-master.yaml, job-node.yaml) by cloning the kube-bench repository:

git clone https://github.com/aquasecurity/kube-bench.git
cd kube-bench # Navigate into the cloned directory to find the YAML files

2. Running kube-bench as a Job

The most common way to run kube-bench is by applying a Job manifest to your cluster. The kube-bench repository provides a generic job.yaml that attempts to auto-detect the node type (master or worker) and run relevant tests.

2.1 Inspecting job.yaml

It's good practice to review the job.yaml (or job-master.yaml/job-node.yaml) before applying it. Here's an example of what job.yaml typically contains:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    metadata:
      labels:
        app: kube-bench
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:latest
          # Note: For repeatable scans, consider using a specific version tag
          # instead of :latest, e.g., aquasec/kube-bench:v0.X.Y
          command: ["kube-bench"] # You can add arguments here, e.g., ["kube-bench", "master"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            # /usr/local/mount-from-host/bin is mounted to access kubectl / kubelet,
            # for auto-detecting the Kubernetes version.
            # You can omit this mount if you specify --version as part of the command.
            - name: usr-bin
              mountPath: /usr/local/mount-from-host/bin # Path inside container
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: "/var/lib/etcd"
        - name: var-lib-kubelet
          hostPath:
            path: "/var/lib/kubelet"
        - name: etc-systemd
          hostPath:
            path: "/etc/systemd"
        - name: etc-kubernetes
          hostPath:
            path: "/etc/kubernetes"
        - name: usr-bin
          hostPath:
            path: "/usr/bin" # Path on the host

(Added note about using specific image versions and clarifying volume mount paths.)

2.2 Starting the Benchmark

Apply the Job manifest (ensure job.yaml is in your current directory, or provide the full path from the cloned repository e.g., ./kube-bench/job.yaml).

kubectl apply -f job.yaml
# Example output:
# job.batch/kube-bench created

2.3 Monitoring the Job and Pods

1. Check pod status: The Job will create a pod. Its name will be like kube-bench-xxxxx.

   kubectl get pods -l app=kube-bench
   # Example output during creation:
   # NAME               READY   STATUS              RESTARTS   AGE
   # kube-bench-j76s9   0/1     ContainerCreating   0          3s

2. Wait for completion: After a short while, the pod should complete its run.

   # Wait for a few seconds/minutes for the job to complete
   kubectl get pods -l app=kube-bench
   # Example output upon completion:
   # NAME               READY   STATUS      RESTARTS   AGE
   # kube-bench-j76s9   0/1     Completed   0          11s

2.4 Retrieving Results

The results of the benchmark are written to the logs of the kube-bench pod.

1. Get the pod name:

   KUBE_BENCH_POD=$(kubectl get pods -l app=kube-bench -o jsonpath='{.items[0].metadata.name}')
   echo "kube-bench pod name: $KUBE_BENCH_POD"

2. View the logs:

   kubectl logs "$KUBE_BENCH_POD"

   Example log output snippet:

   [INFO] 1 Master Node Security Configuration
   [INFO] 1.1 API Server
   ...
   [PASS] 1.1.1 Ensure that the --allow-privileged argument is set to false (Manual)
   ...

   (Formatted log output as generic text.)

3. Alternative: Running Node-Specific Jobs

The kube-bench repository also provides specific job files for master nodes (job-master.yaml) and worker nodes (job-node.yaml). These can be useful if you want to target specific types of nodes or if auto-detection in the generic job.yaml is not working as expected for your setup.

To use them, apply the respective YAML file:

# To run tests specifically for a master node (usually requires scheduling on a master node)
# kubectl apply -f job-master.yaml

# To run tests specifically for a worker node (usually requires scheduling on a worker node)
# kubectl apply -f job-node.yaml

You would then monitor the pods and retrieve logs in the same way as described in section 2.3 and 2.4, adjusting the pod name/label selector if necessary. These specific jobs might use different labels or names.

Home