What is Kubernetes CIS Benchmark?
The Kubernetes CIS Benchmark is published by the Center for Internet Security (CIS), a not-for-profit organization that publishes cybersecurity best practices.
CIS Benchmark best practices are an important first step to securing Kubernetes in production by hardening Kubernetes environments. Several open source and commercial tools are available that automatically check Kubernetes clusters to see they are in line with the controls outlined in the benchmark, and flag any non-compliant configurations.
We provide a brief summary of the CIS Benchmark’s best practices, and shows how to use kube-bench to automatically test your Kubernetes deployment for these best practices.
In this article, you will learn:
- Kubernetes CIS Benchmark Best Practices
- Control Plane Components
- Control Plane Configuration
- Worker Nodes
- Policies
- Using kube-bench to Test Your Deployment for CIS Best Practices
- Kubernetes Security with Aqua
Kubernetes CIS Benchmark Best Practices
The Kubernetes CIS Benchmark contains over 250 pages of details on how to secure Kubernetes deployments. Below we provide a brief summary of the recommendations provided in each section of the benchmark.
Important: Most of the recommendations are relevant for Kubernetes deployed directly by the organization, but not for managed Kubernetes services such as Amazon Elastic Kubernetes Service (AKS), Google Kubernetes Engine (GKE) or Openshift. This is because these services provide a managed control plane, and may have different command line tools compared to standard Kubernetes.
Related content: read our guide to Kubernetes security best practices ›
Control Plane Components
The CIS benchmark makes several recommendations with regard to configuration of the Kubernetes control plane—including the API Server, etcd, and Container Network Interface (CNI).
Master Node Configuration Files
The following table shows critical files you need to secure, and their recommended settings.
| 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
The following table summarizes recommended settings for the 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 set AlwaysAdmit not set AlwaysPullImages is set SecurityContextDeny set (if PodSecurityPolicy not used) ServiceAccount is set NamespaceLifecycle is set PodSecurityPolicy is set NodeRestriction 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
The following table summarizes recommended settings for Controller Manager configuration.
| 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
The following table summarizes recommended settings for Scheduler configuration.
| Configuration Element | Recommended Setting |
| –profiling | false |
| –bind-address | 127.0.0.1 |
etcd
The following table summarizes recommended settings for etcd configuration.
| 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 |
Control Plane Configuration
When configuring the Kubernetes control plane, the Kubernetes CIS Benchmark recommends:
- Not using client certificate authentication for users—Kubernetes enables the use of client certificates for user authentication. However, there is no way to revoke these certificates when a user leaves or loses the credentials. So the recommendation is not to use them.
- Minimal audit policy—Kubernetes can audit requests made to the API server. To ensure there is at least a minimal audit trail, the –audit-policy file flag needs to be set.
- Audit policy coverage—security audit logs must record access and modification of any key cluster resources.
Worker Nodes
The Kubernetes CIS benchmark makes several recommendations for securing configuration files and defining specific configuration settings for the Kubelet on worker nodes.
Worker Node Configuration Files
The following table summarizes recommendations for worker securing configuration files.
| File/Directory to Secure | File Permissions | File Ownership |
| kubelet service file | 644 or stricter | root:root |
| proxy kubeconfig file (if exists) | 644 or stricter | root:root |
| –kubeconfig kubelet.conf | 644 or stricter | root:root |
| certificate authorities file | 644 or stricter | root:root |
| kubelet –config | 644 or stricter | root:root |
Kubelet Configuration
The following table summarizes recommendations for the Kubelet configuration.
| Configuration Element | Recommended Setting |
| –anonymous-auth | false |
| –authorization-mode | AlwaysAllow |
| –read-only-port | 0 |
| –streaming-connection-idle-timeout | Not set to 0 |
| –protect-kernel-defaults | true |
| –make-iptables-util-chains | true |
| –hostname-override | not set |
| –event-qps | 0, or another level that enables sufficient event capture |
| –rotate-certificates | not set to false |
| RotateKubeletServerCertificate | true |
| Kubelet cryptography | Uses strong cryptographic cipher |
| –client-ca-file argument | Ensure these parameters / arguments are set to their appropriate values |
| –tls-cert-file | |
| –tls-private-key-file |
Policies
The Kubernetes CIS benchmark recommends specific policies for Kubernetes elements like RBAC, pods and the container network interface (CNI), to improve security.
RBAC, Service Accounts and Admission Control
The following table summarizes recommendations for the RBAC and Service Accounts.
| Policy Pertains To | Recommended Policy |
| cluster-admin role | Only use where required |
| secrets | Ensure minimal access |
| Roles, ClusterRoles | Minimal use of wildcards |
| Create Pod permission | Ensure minimal access |
| Service Account Tokens | Only mount if/when necessary |
| Privileged containers | Minimize admission to all these types of containers |
| Admission control | Configure Image Provenance using ImagePolicyWebhook |
Pods
The following table summarizes recommendations for pods and sensitive containers.
| Policy Pertains To | Recommended Policy |
| Privileged containers | Minimize admission to all these types of containers |
| Containers sharing one of the following: 1. Host process ID namespace 2. Host IPC namespace 3. Host network namespace | |
| Containers with allowPrivilegeEscalation setting | |
| Root containers | |
| Containers with NET_RAW capability | |
| Containers with added or assigned capabilities |
Network Policies and CNI
The following table summarizes recommendations for Kubernetes networking.
| Policy Pertains To | Recommended Policy |
| CNI | Ensure support of network policies |
| Namespaces | Ensure they have network policies defined |
Secrets Management
The following table summarizes recommendations for Kubernetes secrets.
| Policy Pertains To | Recommended Policy |
| Secrets | Prefer storing as files and not as environment variables |
| Secrets | Prefer using external storage |
Related content: read our guide to Kubernetes secrets ›
General Policies
In addition to the recommendations above, the benchmark recommends:
- Creating administrative boundaries using namespaces, and never using the default namespace
- Using the seccomp profile in docker/default pod definitions
- Using Security Context in Pods and Containers
Using kube-bench to Test Your Deployment for CIS Best Practices
You can use kube-bench to check if your Kubernetes deployment runs according to the best practices defined in the CIS Kubernetes Benchmark. However, please note that there is not a one-to-one match between Kubernetes versions and versions of the CIS benchmark, so you cannot achieve 100% accuracy.
Kube-bench is written as a Go application. It is distributed as a container, and can also be installed and run as a standalone binary. To help you quickly update and extend your test suite according to any benchmark changes, each individual kube-bench test is specified in a YAML file. For easy integration with automation tools, kube-bench supports JSON output.
You can run kube-bench on each individual master and worker node, and learn whether each test fails or passes. Kube-bench can also inspect master nodes of managed Kubernetes clusters in services like Google Kubernetes Engine (GKE) and Amazon Elastic Kubernetes Service (EKS).
Additionally, you can get remediation insights for any detected issue, including specific recommendations. For example, you might need to remove insecure settings on a Kubernetes executable, or restrict the permissions on a configuration file.
Kube-bench lets you immediately determine if your configurations corresponds with CIS best practices, including secure measures for data at rest and in transit, implementation of the least privileges principle, and proper application of user authorization and authentication.
When running kube-bench, you can get four output states:
- PASS – the test ran successfully and the results passed the standards.
- FAIL – the test ran successfully and the results failed to meet the standards. You also receive a remediation output, which either describes how you can fix the configuration, or provides an error message that explains why it was not possible to run the test.
- WARN – the test requires further attention. A remediation output provides specific information regarding the matter.
- INFO – provides informational output that does not require any further action.
Learn more about kube-bench ›
Kubernetes Security with Aqua
Aqua tames the complexity of Kubernetes security with KSPM (Kubernetes Security Posture Management) and advanced agentless Kubernetes Runtime Protection.
Aqua provides Kubernetes-native capabilities to achieve policy-driven, full-lifecycle protection and compliance for K8s applications:
- Kubernetes Security Posture Management (KSPM) – a holistic view of the security posture of your Kubernetes infrastructure for accurate reporting and remediation. Helping you identify and remediate security risks.
- Automate Kubernetes security configuration and compliance – identify and remediate risks through security assessments and automated compliance monitoring. Help you enforce policy-driven security monitoring and governance.
- Control pod deployment based on K8s risk – determine admission of workloads across the cluster based on pod, node, and cluster attributes. Enable contextual reduction of risk with out-of-the-box best practices and custom Open Policy Agent (OPA) rules.
- Protect entire clusters with agentless runtime security – runtime protection for Kubernetes workloads with no need for host OS access, for easy, seamless deployment in managed or restricted K8s environments.
- Open Source Kubernetes Security – Aqua provides the most popular open source tools for securing Kubernetes, including Kube-Bench, which assesses Kubernetes clusters against 100+ tests of the CIS Benchmark, and Kube-Hunter, which performs penetration tests using dozens of known attack vectors.