Kubebench Security Tool

What is Kube-bench?

Kube-bench is a security tool that runs under an Apache 2.0 license, used to verify whether a Kubernetes deployment is secure by running CIS Kubernetes Benchmarkarrow-up-right checks based on the Center for Internet Securityarrow-up-right documentation.

CIS provides more than one hundred benchmarks across multiple vendor product families. The CIS benchmarks have evolved through a distinctive consensus-based process including cybersecurity professionals and subject-matter experts from around the world. CIS benchmarks are unique in that they are consensus-based, best-practice security planning guides developed and accepted by governments, businesses, industries, and academia.

Using easy to update YAML files, it tests multiple component areas of the cluster, advising users of best practice security configurations.

Installing Kube-bench

Users have four methods to install kube-bench.

Download and Install Binaries

Users can manually install and run kube-bench using release binaries. To accomplish this, you must have full access to your Kubernetes cluster nodes. To, note your platform release, then SSH into one of the nodes and run the command related to your specific release. This will install the kube-bench binary for your platform.

Ubuntu/Debian

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.deb -o kube-bench_0.6.2_linux_amd64.deb

sudo apt install ./kube-bench_0.6.2_linux_amd64.deb -f

RHEL

Source

Alternatively, users can download and extract the kube-bench binary.

Then, run the kube-bench command.

circle-info

Info

If the kube-bench binary is manually downloaded, users must specify the location of the configuration file and directory and file.

Clone Repository

Users that have Go installed can clone the repo and use the following installation commands. (again, this is assuming your GOPATH is set).

Container Installation

The following command reproduces the kube-bench binary along with the configuration files within the host from a Docker container.

circle-exclamation

Finally, run ./kube-bench to begin testing.

Example Kube-bench Test on a Sample PES/PMK Cluster

To run the tests, users can create a one-node PMK cluster with master and worker enabled on the same node. SSH onto the node and execute the following commands.

Output of Test Kube-bench Report

This test ran against Kubernetes version 1.20.5. The PMK custom configuration is based on cis-1.20 benchmark.

Kube-bench attempts to auto-detect the Kubernetes version to match the corresponding CIS Benchmark version. Kube-bench also attempts to identify the node components and uses that info to determine which tests to use.

circle-info

Info

Kube-bench tries to follow the CIS Kubernetes Benchmarks tightly. However, the mapping between Kubernetes and CIS benchmark versions is approximate and not exact. By default, kube-bench will ascertain the set of tests to run based on the Kubernetes version running on the nodes. Users may need to have root or sudo rights to access all the config files when running kube-bench from the command line.

Running Kube-bench on a Container

Users do not have to install kube-bench. It can be employed on a host by running it inside a container using the host PID namespace. Using this method, users must mount the /etc and /var directories where the configuration and other files are located on the host. This allows kube-bench to check for their existence and permission levels.

circle-info

Info

Testing requires the use of kubelet or the kubectl binary must reside in your path. This allows it to auto-detect the Kubernetes version.

Users can pass the -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl flag to resolve this. It is also required to pass the kubeconfig credentials. For example:

To use your configurations, transpose them over the default configs located in the /opt/kube-bench/cfg/ folder.

Running Kube-bench on a Kubernetes Cluster

Kube-bench can be run in a pod, but it will need access to the host's PID namespace to check the running processes. It also requires access to several folders where the configuration and other files are located on the host. The job.yaml file noted below can be used to run the tests as a job. For example:

To perform tests on a master node, the pod should be scheduled on that node. This entails setting a nodeSelector and tolerations in the PodSpec settings.

Last updated

Was this helpful?