CIS Kubernetes Benchmark

What is the CIS Kubernetes Benchmark?

CIS stands for Center of Internet Security. It is a global organization that is staffed by professionals, subject matter experts, and people who focus on improving cyber security. The CIS benchmarks are a series of best practices and guidelines that companies should follow to ensure their IT infrastructure is safeguarded against numerous threats and risks. 

There are many types of IT systems and over 140 CIS benchmarks to guide toward optimum cybersecurity. A good example is cloud infrastructure, under which you can find a series of best practices for configuring Kubernetes as well. These are generally termed CIS Kubernetes Benchmarks.

Purpose of CIS Kubernetes Benchmark

CIS Benchmarks give a specific set of guidelines suitable to Kubernetes and ensure the hardened Kubernetes environments. Thus, protecting from common vulnerabilities and misconfigurations. DevOps engineers can use different tools to ensure they configure the Kubernetes clusters according to the Benchmarks and also flag any configuration which isn’t compliant with the CIS standard. 

Different Parts of the CIS Kubernetes Benchmark

The CIS Kubernetes Benchmarks have various parts which help one deduce whether a configuration is compliant or not and to what extent it affects the system. Besides this, the Benchmarks also help companies assign the responsibility of ensuring compliance. These parts include:


CIS Benchmarks have several recommendations underneath each of them. These recommendations have an assessment test wherein the implementation of a recommendation is checked. The recommendation is scored if the checking can be done in an automated fashion. On the other hand, if the checking needs to be done manually, it is known as not scored. Furthermore, the scoring will also determine how secure the system is and how much the implementation of the recommendation can affect the system.


There are two levels of security recommendations. Level 1 comprises basic security measures which do not interfere with the regular functioning of the system. Level 2 includes security measures that address Kubernetes security on a deeper level. While this may ensure compliance, it takes more time to implement and might interfere with the regular functioning of the infrastructure. 


There are two possible results once the assessment ends. Pass means that the recommendation is incorporated into the infrastructure. Fail means it hasn’t been incorporated into the Kubernetes system. Furthermore, the benchmark details the next steps and the remedies DevOps engineers can take to fix the issue and turn the status from Pass to Fail. 


The final part, responsibility, refers to the entity that must incorporate the recommendation. Usually, it’s the organization, but there are also cases where it’s the company and the vendor who provides the cloud service.

Component Configuration

The CIS Benchmark is accepted in the cloud-native community for configuring Kubernetes components. Compliance can be ensured by manual configuration, which can be an arduous task, or preferably by using various tools that can automate the process making it more efficient and secure. Recommended configurations of key components are listed below.

Control Plane Component

Control Plane ComponentFile/Directory to SecureFile PermissionsFile Ownership
API ServerPod specification file644 or stricterroot:root
Controller ManagerPod specification file644 or stricterroot:root
Controller Managercontroller-manager.conf644 or stricterroot:root
SchedulerPod specification file644 or stricterroot:root
Schedulerscheduler.conf644 or stricterroot:root
etcdPod specification file644 or stricterroot:root
Container NetworkCNI file644 or stricterroot:root
etcdData directory700 oir stricteretcd:etcd
kubeadmadmin.conf644 or stricterroot:root
Kubernetes PKIPKI directoryroot:root
Kubernetes PKIPKI certificate644 or stricter
Kubernetes PKIPKI key files600

API Server

Configuration ElementRecommended Setting
–basic-auth-filenot set
–basic-auth-filenot set
–token-auth-filenot set
–authorization-modeAlwaysAllow, includes Node and RBAC
admission control pluginEventRateLimit is setAlwaysAdmit not set AlwaysPullImages is set SecurityContextDeny set (if PodSecurityPolicy not used)ServiceAccount is setNamespaceLifecycle is setPodSecurityPolicy is setNodeRestriction is set
–insecure-bind-addressnot set
encryption providersOnly use strong cryptographic ciphers
–etcd-certfileEnsure these parameters / arguments are set to their appropriate values
–request-timeout argument

Controller Manager

Configuration ElementRecommended Setting
–terminated-pod-gc-thresholdEnsure these parameters / arguments are set to their appropriate values


Configuration ElementRecommended Setting


Configuration ElementRecommended Setting
Certificate AuthorityUse a unique CA
–cert-fileEnsure these parameters / arguments are set to their appropriate values

Besides these there are numerous recommendations on how worker nodes, pods, kubelet, and a few other parts must be configured. Below is an example of how the worker node is made to run with CIS Benchmark compliant recommendations.

Example of How to Scan K8s Configuration Against the CIS Framework Using Kubescape

Kubescape has numerous frameworks to test against. It enables engineers to automatically scan the configurations of the clusters and various resources against different frameworks. CIS is one of the available frameworks using the CLI, an individual can find all the misconfigurations and, fix them using assisted remediation. Here’s how it works:

Step 1: Scan the K8 with the CIS framework using the following command:

$ kubescape scan framework CIS --enable-host-scan --submit 

Step 2: Once you run the command, you get a series of passed and failed resource configurations. Head to the dashboard, and under the configuration scanning section, you’ll see the list of resources that can be remediated.

Step 3: Go to one of the resources and click the remediation suggestion. You’ll be redirected to the resource’s code, wherein you’ll get a suggestion of what code needs to be added, changed or deleted.

Step 4: Make the suggested change and scan the cluster again. You’ll no longer see the specific resource failing on the specific control. 

Repeating these steps to remediate other resources will improve your compliance. Scanning at regular intervals will help you avoid drifting away from compliance.

Get the latest, first

Continue to Slack

Get the information you need directly from our experts!

new-messageContinue as a guest