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:
Scoring
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.
Levels
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.
Results
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.
Responsibility
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 CIS benchmark 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 Component | File/Directory to Secure | File Permissions | File Ownership |
API Server | Pod specification file | 644 or stricter | root:root |
Controller Manager | Pod specification file | 644 or stricter | root:root |
Controller Manager | controller-manager.conf | 644 or stricter | root:root |
Scheduler | Pod specification file | 644 or stricter | root:root |
Scheduler | scheduler.conf | 644 or stricter | root:root |
etcd | Pod specification file | 644 or stricter | root:root |
Container Network | CNI file | 644 or stricter | root:root |
Interface | |||
etcd | Data directory | 700 oir stricter | etcd:etcd |
kubeadm | admin.conf | 644 or stricter | root:root |
Kubernetes PKI | PKI directory | root:root | |
Kubernetes PKI | PKI certificate | 644 or stricter | |
Kubernetes PKI | PKI key files | 600 |
API Server
Configuration Element | Recommended Setting |
–anonymous-auth | false |
–basic-auth-file | not set |
–anonymous-auth | false |
–basic-auth-file | not set |
–token-auth-file | not set |
–kubelet-https | true |
–authorization-mode | AlwaysAllow, includes Node and RBAC |
admission control plugin | EventRateLimit is setAlwaysAdmit not set AlwaysPullImages is set SecurityContextDeny set (if PodSecurityPolicy not used)ServiceAccount is setNamespaceLifecycle is setPodSecurityPolicy is setNodeRestriction is set |
–insecure-bind-address | not set |
–insecure-port | 0 |
–secure-port | 0 |
–profiling | false |
–audit-log-path | false |
–audit-log-maxage | 30 |
–service-account-lookup | True |
encryption providers | Only use strong cryptographic ciphers |
–etcd-certfile | Ensure these parameters / arguments are set to their appropriate values |
–etcd-keyfile | |
–tls-cert-file | |
–tls-private-key-file | |
–client-ca-file | |
–etcd-cafile | |
–encryption-provider-config | |
–kubelet-client-certificate | |
–kubelet-client-key | |
–kubelet-certificate-authority | |
–audit-log-maxbackup | |
–audit-log-maxsize | |
–request-timeout argument | |
–service-account-key-file |
Controller Manager
Configuration Element | Recommended Setting |
–profiling | false |
–use-service-account-credentials | true |
RotateKubeletServerCertificate | true |
–bind-address | 127.0.0.1 |
–terminated-pod-gc-threshold | Ensure these parameters / arguments are set to their appropriate values |
–service-account-private-key-file | |
–root-ca-file |
Scheduler
Configuration Element | Recommended Setting |
–profiling | false |
–bind-address | 127.0.0.1 |
etcd
Configuration Element | Recommended Setting |
–client-cert-auth | true |
–auto-tls | true |
–peer-client-cert-auth | true |
–peer-auto-tls | true |
Certificate Authority | Use a unique CA |
–cert-file | Ensure these parameters / arguments are set to their appropriate values |
–key-file | |
–peer-cert-file | |
–peer-key-file |
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.