Kubernetes CIS Benchmark: Best Practices in Brief

Review the CIS Benchmark security best practices, summarized in a few short tables, and learn about automated security testing with kube-bench.

February 8, 2021

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

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 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
Interface
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

The following table summarizes recommended settings for the API server.

Configuration ElementRecommended Setting
–anonymous-authfalse
–basic-auth-filenot set
–anonymous-authfalse
–basic-auth-filenot set
–token-auth-filenot set
–kubelet-httpstrue
–authorization-modeAlwaysAllow, includes Node and RBAC
admission control pluginEventRateLimit 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-addressnot set
–insecure-port0
–secure-port0
–profilingfalse
–audit-log-pathfalse
–audit-log-maxage30
–service-account-lookupTrue
encryption providersOnly use strong cryptographic ciphers
–etcd-certfileEnsure 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 ElementRecommended Setting
–profilingfalse
–use-service-account-credentialstrue
RotateKubeletServerCertificatetrue
–bind-address127.0.0.1
–terminated-pod-gc-thresholdEnsure 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 ElementRecommended Setting
–profilingfalse
–bind-address127.0.0.1

etcd

The following table summarizes recommended settings for etcd configuration.

Configuration ElementRecommended Setting
–client-cert-authtrue
–auto-tlstrue
–peer-client-cert-authtrue
–peer-auto-tlstrue
Certificate AuthorityUse a unique CA
–cert-fileEnsure 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 SecureFile PermissionsFile Ownership
kubelet service file644 or stricterroot:root
proxy kubeconfig file (if exists)644 or stricterroot:root
–kubeconfig kubelet.conf644 or stricterroot:root
certificate authorities file644 or stricterroot:root
kubelet –config644 or stricterroot:root

Kubelet Configuration

The following table summarizes recommendations for the Kubelet configuration.

Configuration ElementRecommended Setting
–anonymous-auth false
–authorization-modeAlwaysAllow
–read-only-port0
–streaming-connection-idle-timeoutNot set to 0
–protect-kernel-defaultstrue
–make-iptables-util-chainstrue
–hostname-overridenot set
–event-qps0, or another level that enables sufficient event capture
–rotate-certificatesnot set to false
RotateKubeletServerCertificatetrue
Kubelet cryptographyUses strong cryptographic cipher
–client-ca-file argumentEnsure 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 ToRecommended Policy
cluster-admin roleOnly use where required
secretsEnsure minimal access
Roles, ClusterRolesMinimal use of wildcards
Create Pod permissionEnsure minimal access
Service Account TokensOnly mount if/when necessary
Privileged containersMinimize admission to all these types of containers
Admission controlConfigure Image Provenance using ImagePolicyWebhook

Pods

The following table summarizes recommendations for pods and sensitive containers.

Policy Pertains ToRecommended Policy
Privileged containersMinimize 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 ToRecommended Policy
CNIEnsure support of network policies
NamespacesEnsure they have network policies defined

Secrets Management

The following table summarizes recommendations for Kubernetes secrets.

Policy Pertains ToRecommended Policy
SecretsPrefer storing as files and not as environment variables
SecretsPrefer 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.