KCSA — CIS Kubernetes Benchmark

8 minute read

CIS Kubernetes Benchmark

The CIS Kubernetes Benchmark is one of the most widely adopted security configuration guides for Kubernetes. For the KCSA exam, you must understand what CIS is, what the benchmark covers, and how tools like kube-bench automate compliance checking against it.

What Is CIS?

The Center for Internet Security (CIS) is a nonprofit organization that publishes security best practices and configuration guidelines for a wide range of technologies.

CIS produces two key types of resources:

Resource Purpose
CIS Benchmarks Detailed, consensus-based configuration guides for specific platforms
CIS Controls Prioritized set of cybersecurity best practices (formerly SANS Top 20)

CIS Benchmarks exist for operating systems (Ubuntu, RHEL), cloud platforms (AWS, Azure, GCP), databases, web servers, and — critically for the KCSA — Kubernetes.

CIS Benchmarks are developed through a community consensus process involving security practitioners, vendors, and subject matter experts worldwide.

CIS Kubernetes Benchmark Overview

The CIS Kubernetes Benchmark is a comprehensive document that provides prescriptive, consensus-based security configuration guidance for Kubernetes clusters. It is organized into sections that map directly to Kubernetes architectural components.

Key Characteristics

  • Version-specific — each benchmark targets a specific Kubernetes version (e.g., CIS Kubernetes Benchmark v1.8 for Kubernetes 1.27+)
  • Prescriptive — provides exact configuration flags, file permissions, and settings to check
  • Consensus-based — developed and reviewed by the security community
  • Free to download — available from the CIS website (registration required)
  • Level 1 and Level 2 — two profile levels with increasing security strictness

Profile Levels

Level Description Impact
Level 1 Essential security settings that can be applied without significant performance impact Minimal disruption — suitable for most environments
Level 2 Defense-in-depth settings that may reduce functionality or performance May affect usability — suitable for high-security environments

Level 1 recommendations are considered the minimum baseline for any production Kubernetes cluster.

Benchmark Sections

The CIS Kubernetes Benchmark is organized into five major sections, each targeting a different architectural layer of the cluster.

Section Scope Examples
1 — Control Plane Components API server, controller manager, scheduler API server flags (--anonymous-auth=false), TLS configuration, audit logging
2 — etcd etcd server configuration Encryption at rest, client certificate authentication, peer TLS
3 — Control Plane Configuration Authentication, authorization, admission RBAC enabled, no system:anonymous ClusterRoleBindings, admission controllers active
4 — Worker Nodes Kubelet, proxy, node configuration Kubelet anonymous auth disabled, file permissions on certs, read-only port disabled
5 — Policies Cluster-wide security policies RBAC least privilege, Pod Security Standards, Network Policies, Secret encryption

Section 1: Control Plane Components

Control plane components are the brain of the cluster. A misconfigured API server or scheduler can expose the entire cluster.

Key checks include:

  • API Server — disable anonymous authentication, enable audit logging, set appropriate authorization mode (RBAC), restrict insecure port, ensure TLS certificates are configured
  • Controller Manager — use individual service account credentials, bind to localhost, set --use-service-account-credentials=true
  • Scheduler — bind to localhost, disable profiling, set proper TLS configuration

Section 2: etcd

etcd stores all cluster state — it is the most sensitive component. If etcd is compromised, the entire cluster is compromised.

Key checks include:

  • Enable client certificate authentication (--client-cert-auth=true)
  • Encrypt etcd communication with TLS (--cert-file and --key-file)
  • Enable peer TLS for multi-node etcd clusters
  • Restrict etcd data directory permissions to 700
  • Enable encryption at rest for Kubernetes Secrets stored in etcd

Section 3: Control Plane Configuration

This section focuses on how authentication, authorization, and admission are configured at the cluster level.

Key checks include:

  • RBAC is the authorization mode (not ABAC or AlwaysAllow)
  • No system:anonymous ClusterRoleBinding exists
  • Required admission controllers are enabled (e.g., NodeRestriction, PodSecurity)
  • Client certificate authentication is properly configured

Section 4: Worker Nodes

Worker nodes run your actual workloads. A compromised node means compromised pods.

Key checks include:

  • Kubelet anonymous authentication is disabled (--anonymous-auth=false)
  • Kubelet authorization mode is set to Webhook (not AlwaysAllow)
  • Read-only port is disabled (--read-only-port=0)
  • Kubelet certificate rotation is enabled
  • File permissions on kubelet configuration and certificates are restrictive

Section 5: Policies

Policies are cluster-wide controls that govern what workloads can do.

Key checks include:

  • RBAC roles follow least privilege (no wildcard * permissions)
  • Pod Security Standards are enforced (restrict privileged containers)
  • Network Policies are defined for every namespace
  • Secrets are encrypted at rest
  • Service account tokens are not auto-mounted when not needed

Scored vs Not-Scored Recommendations

Each recommendation in the CIS Benchmark is classified as either Scored or Not Scored.

Type Meaning Example
Scored Can be objectively verified through automated checks. Failure reduces the compliance score. “Ensure --anonymous-auth is set to false”
Not Scored Requires manual review, judgment, or context. Not included in automated compliance scores. “Ensure that the cluster has a security policy defined”

For the KCSA exam, understand that not-scored does not mean unimportant — it simply means the recommendation requires human judgment to verify.

kube-bench: Automating CIS Compliance

kube-bench is an open-source tool from Aqua Security that automates checking whether a Kubernetes cluster meets the CIS Kubernetes Benchmark.

How kube-bench Works

  1. Detects the Kubernetes version running on the node
  2. Selects the appropriate CIS Benchmark version
  3. Runs checks against the node’s configuration files, running processes, and command-line flags
  4. Produces a report with PASS, FAIL, WARN, and INFO results

Running kube-bench

kube-bench can be run as a container, a Job, or a binary:

# Run as a Kubernetes Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Check the results
kubectl logs job/kube-bench

Sample Output

[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod spec file permissions are set to 644 or more restrictive
[PASS] 1.1.2 Ensure that the API server pod spec file ownership is set to root:root
[FAIL] 1.1.3 Ensure that the controller manager pod spec file permissions are set to 644 or more restrictive
[PASS] 1.1.4 Ensure that the controller manager pod spec file ownership is set to root:root
...

== Summary total ==
43 checks PASS
12 checks FAIL
7  checks WARN
0  checks INFO

Interpreting Results

Status Meaning Action
PASS The check meets the CIS recommendation No action needed
FAIL The check does not meet the CIS recommendation Remediate according to the benchmark guidance
WARN The check could not be automatically verified (not scored) Manual review recommended
INFO Informational — no pass/fail determination Review for context

kube-bench does NOT fix problems — it only identifies them. Remediation is a separate step.

CIS Benchmarks in Managed Kubernetes

When running Kubernetes on managed platforms (EKS, GKE, AKS), the cloud provider manages the control plane. This means:

Responsibility Self-Managed Managed (EKS/GKE/AKS)
Control plane configuration (Section 1) Your responsibility Provider manages — you cannot change API server flags
etcd configuration (Section 2) Your responsibility Provider manages — etcd is hidden from you
Control plane config (Section 3) Your responsibility Shared — you manage RBAC, provider manages auth backends
Worker node configuration (Section 4) Your responsibility Your responsibility — you manage node images and kubelet config
Policies (Section 5) Your responsibility Your responsibility — you define RBAC, PSS, Network Policies

Cloud providers publish their own CIS Benchmark versions:

  • CIS Amazon EKS Benchmark
  • CIS Google Kubernetes Engine Benchmark
  • CIS Azure Kubernetes Service Benchmark

For the KCSA exam, know that in managed Kubernetes, sections 1 and 2 (control plane and etcd) are largely the provider’s responsibility, while sections 4 and 5 (worker nodes and policies) remain the customer’s responsibility.

CIS Benchmark for Container Images

Beyond cluster configuration, CIS also publishes benchmarks for Docker and container runtimes. Key image-related recommendations include:

  • Use trusted base images — only pull from verified registries
  • Scan images for vulnerabilities — use tools like Trivy, Grype, or Snyk
  • Do not store secrets in images — use Kubernetes Secrets or external secret managers
  • Use minimal base images — prefer distroless or Alpine to reduce attack surface
  • Set a non-root USER — containers should not run as root by default
  • Use specific image tags or digests — avoid latest tag in production
# Good practice: non-root user, specific tag, read-only filesystem
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: myregistry.io/myapp:v1.4.2@sha256:abc123...
    securityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false

CIS Benchmark Lifecycle

The CIS Kubernetes Benchmark is a living document. Understanding how it evolves is important for maintaining compliance over time.

Phase Description
Draft Community members propose new or updated recommendations
Consensus Review Subject matter experts review and vote on changes
Publication New benchmark version is released aligned with a Kubernetes version
Adoption Organizations update their compliance checks (kube-bench rules)
Superseded Older benchmark versions are replaced by newer ones

Version Alignment

Each CIS Kubernetes Benchmark targets a specific Kubernetes version range. When upgrading Kubernetes, you should also update to the corresponding CIS Benchmark version.

CIS Benchmark Version Kubernetes Version Key Changes
v1.6 1.20+ Pod Security Policy recommendations
v1.7 1.24+ PSP removed, Pod Security Admission added
v1.8 1.27+ Updated admission controller guidance

Always use the benchmark version that matches your Kubernetes version. Running an outdated benchmark version may miss new security recommendations or check for deprecated features.

Common CIS Benchmark Failures

Knowing the most frequently failed checks helps prioritize remediation and prepares you for exam scenarios.

Common Failure CIS Section Risk Fix
Anonymous auth enabled on API server 1 Unauthenticated API access Set --anonymous-auth=false
etcd encryption at rest not enabled 2 Secrets stored in plaintext Configure EncryptionConfiguration
Kubelet read-only port open 4 Information disclosure Set --read-only-port=0
Missing Network Policies 5 Unrestricted pod-to-pod traffic Define default-deny Network Policies per namespace
Wildcard RBAC permissions 5 Over-privileged access Replace * with explicit resource/verb lists
Default service account used 5 Shared identity across pods Create dedicated service accounts per workload

Key Takeaways for the Exam

Concept What to Remember
CIS Center for Internet Security — nonprofit that publishes security configuration benchmarks
CIS Kubernetes Benchmark Comprehensive, version-specific security configuration guide organized by component
Five sections Control Plane, etcd, Control Plane Config, Worker Nodes, Policies
Two profile levels Level 1 (essential, low impact) and Level 2 (defense-in-depth, may impact functionality)
Scored vs Not Scored Scored = automatically verifiable; Not Scored = requires manual review
kube-bench Aqua Security tool that automates CIS Benchmark checks; reports PASS/FAIL/WARN/INFO
Managed K8s Provider handles control plane (Sections 1-2); customer handles nodes and policies (Sections 4-5)
kube-bench does not remediate It identifies issues — fixing them is a separate process

Next: NIST & Industry Standards

Updated:

You may also enjoy