Comparing the Leading Tools That Scan Against the CIS Kubernetes Benchmark Framework

CIS Benchmarks are a focused set of guidelines for the secure configuration, vulnerability detection, and threat remediation of distributed workloads. In this article, we compare the leading tools that scan against the CIS Kubernetes benchmark framework.

Security frameworks help modern software organizations define their risk management processes and platform requirements to prevent cyber threats. The Center for Internet Security (CIS) is a non-profit organization that offers tested and proven best practices to help organizations  protect their systems and networks from security threats. 

CIS Benchmarks are a set of best practice security configuration guidelines for various technology platforms and software. In this article, we will discuss the CIS Benchmark for Kubernetes, its recommended hardening policies, and popular tools that scan an existing cluster to validate against the CIS Benchmark. 

What Is the CIS Benchmark for Kubernetes?

The CIS Kubernetes Benchmark puts forward recommended procedures to set up Kubernetes clusters and workloads with the aim of adopting a strong security posture. Unlike other frameworks, the CIS Benchmark offers detailed, well-defined, consensus-driven recommendations for securely creating configuration files, avoiding misconfigurations of the control plane, and adopting security policies for hardening containerized workloads.

Levels of Security for CIS Policies in Kubernetes 

CIS recommendations are typically categorized according to the layer of the Kubernetes stack to which they are applied. There are three levels of security for CIS Kubernetes policies.

Cluster-Level Security

Cluster-level security recommendations encompass the physical infrastructure, configurable components, and services that are part of cluster operations. Whether clusters are built on-premises or in the cloud, the CIS Benchmark offers recommended practices to detect cluster vulnerabilities while helping define secure network access policies for cluster resources.

Node OS-Level Security

Kubernetes nodes are physical or virtual machines used to host containerized workloads in Kubernetes clusters. Node-level recommendations consist of various configuration guidelines to secure nodes at the operating system level. Although the recommended standards are mostly similar for both the control plane and worker nodes, organizations should consider additional security controls for control plane hosts, as a breach may potentially result in a cluster-wide compromise.

Workload-Level Security

Workload-level security recommendations cover hardening practices for containers, code, and other applications running on the data plane. Suggested practices include using stable images, adopting secure coding practices, securing the container registry, and all other techniques that ensure Kubernetes deployment objects only run safe workloads. 

Benefits of Leveraging CIS Benchmark for Kubernetes Security

There are several merits to using the CIS Kubernetes Benchmark for security hardening. 

Improved Security Posture

The benchmark is a comprehensive set of guidelines that encompass all components of the Kubernetes ecosystem. It provides actionable insights on cluster vulnerabilities, common attack patterns, and remediation options. While in-house adoption of CIS-recommended practices is a common approach, major cloud providers also offer CIS-hardened images for secure, scalable, and on-demand computing environments out of the box.

Updated Guidance on Container Security

CIS Benchmarks are frequently updated to address emerging vulnerabilities and exploits. Apart from offering recommended practices, CIS guidelines also offer up-to-date, practical steps that stay relevant across all stages of a cluster lifecycle. 

Straightforward Vulnerability Assessment

The benchmark is written for rapid security assessment of all layers of a Kubernetes ecosystem. These guidelines are simple and straightforward to implement, allowing cluster administrators to perform security audits without requiring extensive investment in resource upskilling or tool licenses.

Based on Collective Knowledge and Expertise

CIS recommendations are developed through a consensus review process by bringing together experts from a diverse set of backgrounds. These include auditors, security practitioners, legal experts, software developers, federal agencies, etc. The guidelines are based on a combination of industry standards and best practices, real-world threat intelligence, threat modeling, risk management, and compliance requirements. This approach helps ensure that the guidelines and recommendations are comprehensive, relevant, and effective in protecting against cyber threats.

Standard, Repeatable Security Practices

CIS builds its benchmarks based on tried and tested best practices, helping enterprises quickly adopt an iterative cycle of security hardening. The framework acts as an essential blueprint for the scalable implementation of security controls. Hence, it is applicable to clusters of different sizes and complexity. .

Maps to Major Compliance Frameworks

CIS controls map to a number of other security frameworks to act as a starting point for regulatory and legal compliance. For example, the benchmark aligns with several compliance frameworks including the NIST Cybersecurity Framework, SOC 2, PCI DSS, HIPAA, CMMC, FISMA, and NERC CIP.

CIS Kubernetes Hardening Recommendations

The following are some recommendations for the adoption of CIS compliance on a Kubernetes cluster at scale.

Control Plane Configuration

The control plane runs crucial cluster functions, including cluster state and configuration data. Control plane exploits are one of the prime targets of attackers since a successful attack often leads to a system-wide compromise. The following set of CIS guidelines offers recommendations for the secure configuration of various control plane processes. 

Authentication and Authorization

Since authorization and authentication mechanisms help control access to the cluster’s services and resources, securing this function  is important to maintaining cluster integrity. 

• CIS 3.1.1: As Kubernetes does not support revoking credentials even after they are compromised, cluster users should not be allowed to use client certificate authentication. An alternative remediation is to either use third-party tools or Kubernetes OpenID Connect for authentication. 

Logging and Auditing

The logging functionality systematically records access requests issued to the API server, providing a centralized resource to detect malicious events in a cluster. The CIS Benchmark includes two recommendations to be applied to the control plane  for logging and audit management:

• CIS 3.2.1: Organizations must enforce a minimal audit policy for allowing Kubernetes to audit requests made to the API server.
• CIS 3.2.2: The audit policy and log should cover key security concerns of the cluster, including information on the modification of and access to critical cluster components. 

Worker Nodes

Worker nodes host containers that run and control cluster workloads. Gaining access to worker nodes allows attackers to inject malicious payloads into the cluster, leading to exploits such as command injection, remote code execution, and cross-site scripting.

Although the following set of CIS guidelines applies to components running on the cluster’s worker nodes, organizations can also apply these recommendations to master nodes whenever possible.

Worker Node Configuration Files

Some recommendations for worker node configuration files include:

• CIS 4.1.1: Restrict the kubelet service file permissions to 600 or more for allowing only administrators to retain edit privileges.
• CIS 4.1.2: Set the kubelet service file’s ownership to root:root for maintaining the file’s integrity.
• CIS 4.1.3: Restrict the kubeconfig file of kube-proxy to 600 or more, and make sure only admins can edit it. 

• CIS 4.1.4: Set the kube-proxy’s kubeconfig file ownership to root:root to maintain the file’s integrity.
• CIS 4.1.5: Set the kubelet.conf file permissions to 600 or more to prevent malicious configuration changes of worker nodes.

Kubelet

The Kubelet service runs as an agent on each node, controlling pods and performing node-specific operations. Unauthorized access to the Kubelet allows hackers to access pod controller APIs, subsequently compromising an entire cluster’s security.

Some key CIS recommendations for Kubelet configuration include:

• CIS 4.2.1: Set the –anonymous-auth argument to false for restricting anonymous requests to be served by the Kubelet server.
• CIS 4.2.2: Do not set the default –authorization-mode argument to AlwaysAllow for restricting all unauthorized requests.
• CIS 4.2.3: Set the –client-ca-file argument to only authenticate using the Kubelet certificate.
• CIS 4.2.4: Set the –read-only-port argument to 0 to disable the port from hacking attempts.
• CIS 4.2.5: Do not set the –streaming-connection-idle-timeout argument to 0 to ensure connections are timed out only after a set duration.

Policies

Policies are key security controls of a Kubernetes environment, as they enforce service authorization and compliance. CIS hardening recommendations for security policies can be broken down into the following categories. 

RBAC and Service Accounts

Role-based access control (RBAC) is a key security mechanism that ensures entities (groups, users, and workloads) can only access the resources required to perform their functions. Hardening recommendations for RBAC and service account policies include:

• CIS 5.1.1: Only use the RBAC cluster-admin role where required to avoid misuse of admin privileges.
• CIS 5.1.2: Restrict secrets so that they are accessed by a smaller user group.
• CIS 5.1.3: Use wildcards minimally in Roles and ClusterRoles to support the principle of least privilege.
• CIS 5.1.4: Restrict user group permissions for creating pods to a minimum. 
• CIS 5.1.5: Use the default service minimally for easier audit of workload permissions. 

Pod Security Admission (PSA)

Kubernetes uses a default pod security admission process for validating and admitting pods into a cluster. This process ensures that only trusted pods are admitted and that all pods conform to the cluster’s security policies. 

CIS hardening recommendations for pod security admission include:

• CIS 5.2.1: Restrict the admission of privileged containers to the lowest minimum possible.
• CIS 5.2.2: Restrict the admission of containers allowed to share the host’s process ID namespace.
• CIS 5.2.3: Restrict the admission of containers allowed to share the host’s IPC namespace.
• CIS 5.2.4: Restrict the admission of containers allowed to share the host’s network namespace.
• CIS 5.2.5: Restrict the admission of containers allowed to operate with the allowPrivilegeEscalation flag set as true.

Network and CNI Policies

Kubernetes network policies help control cluster traffic flow at the level of an IP address or port by specifying rules and constraints. Clusters require a network plugin (such as CNI) to enforce network policies. Hardening network policies are recommended to be administered at the master node level. These include:

• CIS 5.3.1: CNI plugins used within a cluster should support Kubernetes network policies to ensure those plugins are able to control cluster traffic.
• CIS 5.3.2: All namespaces should have at least one network policy defined. 

Secrets Management

Kubernetes Secrets help to store and inject information into clusters. Secrets provide flexibility in defining deployment objects while also offering control over how sensitive data, such as passwords, SSH keys, and certificates, are used in a cluster.

CIS hardening recommendations for Secrets management policies include:

• CIS 5.4.1: Pass secrets as files instead of through environment variables.
• CIS 5.4.2: Save secrets on an external service for efficient management and compliance.

General Policies

These policies are for securing general aspects of a cluster, such as namespace configuration guidelines and policies for object deployment.

• CIS 5.7.1: Attach resources to namespaces for isolating Kubernetes cluster objects.
• CIS 5.7.2: Enable secure computing mode (seccomp) through pod definitions to ensure workloads operate with restricted privileges.
• CIS 5.7.3: Apply appropriate pod and container-level security contexts.
• CIS 5.7.4: Instead of using the default namespace, use custom namespaces for resource segregation.

Popular Tools to Implement CIS Controls for Secure Kubernetes Clusters 

The continuous evaluation of multiple services, components, and geographically distributed clusters is a complex undertaking. In addition, hardening a Kubernetes cluster against the CIS Benchmark is a multi-faceted proposition that requires a thorough evaluation of policies, services, code, and cluster infrastructure. 

To relieve teams of the arduous work required to achieve CIS compliance on Kubernetes clusters, organizations can leverage tools that implement the CIS Kubernetes Benchmark out of the box. The following are some of the most popular solutions.

Kube-Bench

An open-source Go-based platform, Kube-Bench checks if the cluster setup conforms to best practices documented in the CIS Kubernetes Benchmark. For easy updates and reusability of test cases as the cluster grows, it allows test templates to be written in YAML. 

Kube-Bench can be run inside a pod, where it relies on access to the host’s PID namespace to check for active events and processes. To harden clusters directly using CSI guidelines, the tool performs tests and assigns [WARN] or [FAIL] labels to configurations that require attention.

Organizations can install the tool to benchmark cluster configurations against CIS guidelines in several different ways, including:

• Kube-Bench CLI
• Kubernetes jobs
• CronJobs

Features

• Free and open-source
• Customized for the CIS Benchmark
• Can be deployed as a container
• Tests are built in YAML, making them easy to customize for different clusters

Challenges

• Lacks one-to-one mapping with Kubernetes releases
• Manually operated scans
• No remediation recommendations

Checkov

Checkov is a static code analysis tool purpose-built for infrastructure-as-code platforms, such as Kubernetes. The graph-based tool can implement CIS controls and benchmark requirements through manifest scanning of cluster resources. 

Checkov’s out-of-the-box library of policies covers up to 60% of the older CIS Kubernetes Benchmark version 1.6.0. The tool also comes with Dockerfile misconfiguration scanning capabilities to help cluster administrators build secure containers in accordance with CIS guidelines.

Features

• Includes audit history
• Native support of version control system integrations

Challenges

• Only performs static code analysis
• Lacks comprehensive misconfiguration scanning of worker nodes and cluster 

Kubernetes Security Operations Center (KSOC)

KSOC is an event-driven SaaS platform that helps automatically scan Kubernetes clusters for vulnerabilities and misconfigurations. The tool also implements image scanning to help evaluate all container images and related dependencies. 

KSOC’s identity and entitlement feature enables the definition and examination of access control policies by auditing RBAC and service roles. With KSOC, cluster teams can define granular policies for all distributed components across different deployment environments, enabling the seamless enforcement of CIS guidelines across multi-cloud and hybrid-cloud clusters. 

Features

• Automated remediation
• Image scanning
• Event-based detection

Challenges

• Complex to implement

Kubescape

Kubescape is an open-source Kubernetes security platform that acts as a single pane of glass for risk analysis, security compliance, vulnerability mitigation, and RBAC visualization of Kubernetes clusters. The platform measures the risk of your Kubernetes clusters, configuration manifests, and CI/CD pipelines based on CIS and other benchmarks, including NSA, MITRE. 

Kubescape’s automated evaluation tracks risk scores over time. It helps assess how well your Kubernetes ecosystem and its underlying DevOps-based workflows are improving security. Kubsescape can generate reports based on the CIS Benchmark. Scan results through Kubescape are presented in a JSON format, a command-line table, or in a  cloud-based UI (currently only provided via ARMO Platform), which segregates misconfigurations against CIS guidelines, offers remediation advice and highlights configuration drifts. 

Features

• Misconfiguration alerts and automated remediation 
• Easy to set up and use
• Various plugins to integrate with different CI/CD workflow tools
• Reports on trends surrounding misconfigurations and remediation
• Supports CIS Benchmark for Kubernetes v1.23

Challenges

• Does not scan against child CIS Benchmarks (support for EKS and AKS coming soon).

ARMO Platform

ARMO Platform is the enterprise solution based on Kubescape. It’s a ​​multi-cloud Kubernetes and CI/CD security single pane of glass. Features include: risk analysis, security compliance, misconfiguration and image vulnerability scanning, RBAC visualization. All supporting compliance with the Kubernetes CIS benchmark.

Features

• Self-service, simple and easily actionable for DevOps, while giving security the full risk profile picture for governance purposes. 
• Brings developers, DevSecOps and security professionals to a single platform where they can work together, in the same context.
• Simplifies, makes transparent and reduces the complexity of Kubernetes security and compliance. 
• Gives security professionals visibility and control so they have a continuous view of the Kubernetes security posture and assess risks.

Challenges

• Requires account creation.
• Free edition is limited to the first ten nodes.

CIS Hardening Tools for Kubernetes — How They Differ

Here is a quick look at how the tools differ in hardening Kubernetes against the CIS Benchmark:

Aspect	Kube-Bench	Checkov	KSOC	Kubescape	ARMO Platform
Ease of use	Simple	Moderately technical	Moderately technical	Simple	Simple
Operation mode	Manual	Manual/automatic	Automatic	Automatic	Automatic
Scope and coverage	Covers all aspects of CIS out of the box	Covers up to 60% of CIS guidelines out of the box	Covers CIS guidelines for policies (RBAC and pod security policies)	Dedicated CIS framework to cover all aspects of CIS guidelines	Dedicated CIS framework to cover all aspects of CIS guidelines
Ownership	Open-source	Open-source with an enterprise distribution (Bridgecrew) for managed security	Paid offering	Open-source	Paid offering
Trend and drift analysis	No	Yes	No	Yes	Yes
Misconfiguration remediation	Manual	Manual	Automated	Automated and in place	Automated and in place
Report export	Does not offer native capabilities to generate report	Supports automated report generation and export	Does not offer native capabilities to generate report	Supports automated report generation and export	Supports automated report generation and export in addition to an OOB dashboard

Conclusion

A recent Kubernetes Benchmark Report 2023 shows an overall trend of worsening configuration issues across the surveyed organizations. In addition, there are concerns over the increased complexity of administering security and continuous threat analysis. The CIS Benchmark helps with this by offering actionable recommendations and security practices that encompass various aspects of cluster security, including node hardening, code security, and access controls. 

While adopting recommendations of the benchmark is often a good starting point, maintaining a robust security posture is a continuous process. CIS-compliance tools help reduce manual efforts and the likelihood of error when implementing these guidelines. Some of these tools also automate vulnerability assessment and remediation fixes for building secure clusters, subsequently minimizing the manual overhead and time invested towards cybersecurity readiness.