CKS — Understanding CIS Benchmarks
Exam Context
| Property | Value |
|---|---|
| Domain | Domain 1 — Cluster Setup |
| Weight | 10% |
| Objective | Use CIS benchmark to review the security configuration of Kubernetes components |
Before you can fix security misconfigurations, you need to understand what you’re measuring against. CIS Kubernetes Benchmarks are the authoritative reference — and the CKS exam expects you to know how they’re structured, what they check, and why each check matters.
What Are CIS Kubernetes Benchmarks?
The Center for Internet Security (CIS) publishes consensus-based security configuration guidelines for dozens of platforms, including Kubernetes. The CIS Kubernetes Benchmark is a document that defines hundreds of security checks organized by component.
Each check specifies:
- What to verify (a configuration flag, file permission, or setting)
- Why it matters (the security risk of the misconfiguration)
- How to check it (the exact command to run)
- How to fix it (the remediation step)
CKS perspective: The exam doesn’t expect you to memorize every CIS benchmark ID. But you must understand the structure, know what the major checks cover, and be able to fix common failures.
Who Publishes the Benchmark?
| Property | Details |
|---|---|
| Publisher | Center for Internet Security (CIS) |
| Document | CIS Kubernetes Benchmark |
| Format | PDF, typically 200+ pages |
| Access | Free download from cisecurity.org |
| Update cadence | New version for each major Kubernetes release |
| Automation tool | kube-bench (Aqua Security) |
CIS Benchmark vs Kubernetes Hardening Guide
Don’t confuse the CIS Benchmark with the NSA/CISA Kubernetes Hardening Guide. They’re complementary but different:
| Aspect | CIS Benchmark | NSA/CISA Hardening Guide |
|---|---|---|
| Publisher | Center for Internet Security | NSA & CISA (U.S. government) |
| Level of detail | Specific checks with exact commands | High-level hardening recommendations |
| Automation | kube-bench | No standard automation tool |
| CKS relevance | Directly tested (kube-bench) | Background knowledge |
Benchmark Levels
CIS benchmarks define two levels of security controls. Understanding this distinction is critical for prioritizing remediation.
Level 1 — Essential Security
Level 1 checks represent the minimum security baseline that every Kubernetes cluster should meet. These checks:
- Are practical and achievable on any cluster
- Have minimal impact on cluster functionality
- Address the most critical security risks
- Should never be skipped, even in development environments
Examples of Level 1 checks:
| Check ID | Description | Component |
|---|---|---|
| 1.2.1 | Ensure --anonymous-auth is set to false |
API Server |
| 1.2.6 | Ensure --authorization-mode includes RBAC |
API Server |
| 4.2.1 | Ensure --anonymous-auth is set to false on kubelet |
Kubelet |
| 4.2.6 | Ensure --protect-kernel-defaults is set to true |
Kubelet |
Level 2 — Defense in Depth
Level 2 checks represent stronger security controls that provide defense in depth. These checks:
- May require more planning to implement
- Can affect cluster operations or performance
- Are recommended for production and compliance-sensitive environments
- Build on top of Level 1 controls
Examples of Level 2 checks:
| Check ID | Description | Component |
|---|---|---|
| 1.2.10 | Ensure --enable-admission-plugins includes EventRateLimit |
API Server |
| 1.2.22 | Ensure --audit-log-maxage is set to 30 or as appropriate |
API Server |
| 1.3.2 | Ensure --profiling is set to false on controller-manager |
Controller Manager |
| 4.2.13 | Ensure TLS cipher suites are configured | Kubelet |
When to Use Which Level
| Environment | Recommended Level | Rationale |
|---|---|---|
| Development/Testing | Level 1 | Essential security without operational overhead |
| Staging | Level 1 + selected Level 2 | Test Level 2 controls before production |
| Production | Level 1 + Level 2 | Full security posture |
| Compliance (SOC2, PCI-DSS) | Level 1 + Level 2 mandatory | Regulatory requirements demand both levels |
Scored vs Not-Scored Checks
Every CIS benchmark check is categorized as either Scored or Not Scored. This distinction matters for compliance reporting.
Scored Checks
- Must pass for the cluster to meet the benchmark requirements
- Directly affect compliance scoring
- Have clear, verifiable pass/fail criteria
- Represent security controls with measurable configuration states
Not-Scored Checks
- Are advisory recommendations
- Do not affect the compliance score
- May require organizational context to evaluate
- Often cover operational practices rather than specific configuration flags
Breakdown by Category
| Category | Scored | Not Scored | Typical Focus |
|---|---|---|---|
| Control Plane | ~40 checks | ~10 checks | Flags, file permissions |
| Worker Node | ~20 checks | ~5 checks | Kubelet config, file permissions |
| Policies | ~10 checks | ~15 checks | RBAC, Pod Security, NetworkPolicy (advisory) |
CKS exam tip: The exam focuses on scored checks — specifically the ones that fail. You’ll need to identify failures and fix them. Not-scored checks are background knowledge.
CIS Benchmark Sections
The CIS Kubernetes Benchmark is organized into major sections that map directly to cluster components.
Section 1: Control Plane Components
This is the largest section, covering all master node components.
1.1 — Control Plane Node Configuration Files
Checks file ownership and permissions for critical configuration files:
1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive
1.1.2 Ensure that the API server pod specification file ownership is set to root:root
1.1.3 Ensure that the controller manager pod specification file permissions are set to 600 or more restrictive
1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root
1.1.5 Ensure that the scheduler pod specification file permissions are set to 600 or more restrictive
1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root
1.1.7 Ensure that the etcd pod specification file permissions are set to 600 or more restrictive
1.1.8 Ensure that the etcd pod specification file ownership is set to root:root
Verification example:
# Check API server manifest permissions
stat -c %a /etc/kubernetes/manifests/kube-apiserver.yaml
# Expected: 600 or 644 (depending on benchmark version)
# Check ownership
stat -c %U:%G /etc/kubernetes/manifests/kube-apiserver.yaml
# Expected: root:root
1.2 — API Server
The most critical subsection — API server flags that control authentication, authorization, and audit:
1.2.1 Ensure that the --anonymous-auth argument is set to false
1.2.2 Ensure that the --token-auth-file parameter is not set
1.2.3 Ensure that the --DenyServiceExternalIPs is not set
1.2.6 Ensure that the --authorization-mode argument is not set to AlwaysAllow
1.2.7 Ensure that the --authorization-mode argument includes Node
1.2.8 Ensure that the --authorization-mode argument includes RBAC
1.2.10 Ensure that the admission control plugin EventRateLimit is set
1.2.12 Ensure that the admission control plugin AlwaysPullImages is set
1.2.13 Ensure that the admission control plugin SecurityContextDeny is set
1.2.16 Ensure that the --profiling argument is set to false
1.2.19 Ensure that the --audit-log-path argument is set
1.2.20 Ensure that the --audit-log-maxage argument is set to 30 or as appropriate
1.2.21 Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate
1.2.22 Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate
1.3 — Controller Manager
1.3.1 Ensure that the --terminated-pod-gc-threshold argument is set as appropriate
1.3.2 Ensure that the --profiling argument is set to false
1.3.3 Ensure that the --use-service-account-credentials argument is set to true
1.3.4 Ensure that the --service-account-private-key-file argument is set as appropriate
1.3.5 Ensure that the --root-ca-file argument is set as appropriate
1.3.6 Ensure that the RotateKubeletServerCertificate argument is set to true
1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1
1.4 — Scheduler
1.4.1 Ensure that the --profiling argument is set to false
1.4.2 Ensure that the --bind-address argument is set to 127.0.0.1
Section 2: etcd
Dedicated section for etcd security:
2.1 Ensure that the --cert-file and --key-file arguments are set as appropriate
2.2 Ensure that the --client-cert-auth argument is set to true
2.3 Ensure that the --auto-tls argument is not set to true
2.4 Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate
2.5 Ensure that the --peer-client-cert-auth argument is set to true
2.6 Ensure that the --peer-auto-tls argument is not set to true
2.7 Ensure that a unique Certificate Authority is used for etcd
Section 3: Control Plane Configuration
Covers authentication and authorization policies:
3.1.1 Client certificate authentication should not be used for users
3.2.1 Ensure that a minimal audit policy is created
3.2.2 Ensure that the audit policy covers key security concerns
Section 4: Worker Nodes
4.1 — Worker Node Configuration Files
4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrictive
4.1.2 Ensure that the kubelet service file ownership is set to root:root
4.1.5 Ensure that the --kubeconfig kubelet.conf file permissions are set to 600 or more restrictive
4.1.6 Ensure that the --kubeconfig kubelet.conf file ownership is set to root:root
4.1.9 If the kubelet config.yaml configuration file is being used, validate permissions are set to 600 or more restrictive
4.1.10 If the kubelet config.yaml configuration file is being used, ensure ownership is set to root:root
4.2 — Kubelet
4.2.1 Ensure that the --anonymous-auth argument is set to false
4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow
4.2.3 Ensure that the --client-ca-file argument is set as appropriate
4.2.4 Ensure that the --read-only-port argument is set to 0
4.2.6 Ensure that the --protect-kernel-defaults argument is set to true
4.2.7 Ensure that the --make-iptables-util-chains argument is set to true
4.2.10 Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate
4.2.11 Ensure that the --rotate-certificates argument is not set to false
4.2.12 Verify that the RotateKubeletServerCertificate argument is set to true
4.2.13 Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers
Section 5: Policies
5.1.1 Ensure that the cluster-admin role is only used where required
5.1.2 Minimize access to secrets
5.1.3 Minimize wildcard use in Roles and ClusterRoles
5.1.5 Ensure that default service accounts are not actively used
5.2.1 Ensure that the cluster has at least one active policy control mechanism in place
5.2.2 Minimize the admission of privileged containers
5.2.3 Minimize the admission of containers wishing to share the host process ID namespace
5.2.4 Minimize the admission of containers wishing to share the host IPC namespace
5.2.5 Minimize the admission of containers wishing to share the host network namespace
Benchmark Version Mapping
CIS releases a new benchmark version for each major Kubernetes release. Using the wrong benchmark version will produce inaccurate results.
| CIS Benchmark Version | Kubernetes Version | Release Date |
|---|---|---|
| CIS Benchmark v1.8 | Kubernetes 1.27 | 2023 |
| CIS Benchmark v1.9 | Kubernetes 1.28-1.29 | 2024 |
| CIS Benchmark v1.10 | Kubernetes 1.30-1.31 | 2024 |
| CIS Benchmark v1.11 | Kubernetes 1.32 | 2025 |
How kube-bench handles versions:
# kube-bench auto-detects the Kubernetes version
kube-bench run
# Force a specific benchmark version
kube-bench run --benchmark cis-1.9
# Check which version kube-bench detected
kube-bench version
CKS exam tip: The exam environment uses a specific Kubernetes version, and kube-bench auto-detects it. You won’t need to specify the benchmark version manually, but understanding the mapping helps you cross-reference the CIS PDF.
Security Impact: Compliance Requirements
CIS benchmarks aren’t just academic exercises — they’re a compliance requirement in many regulated industries.
Compliance Framework Mapping
| Compliance Framework | CIS Benchmark Requirement | Level |
|---|---|---|
| SOC 2 Type II | Infrastructure security controls must be documented and verified | Level 1 + Level 2 |
| PCI-DSS v4.0 | Container security benchmarks required for cardholder data environments | Level 1 + Level 2 |
| HIPAA | Technical safeguards for electronic protected health information | Level 1 minimum |
| ISO 27001 | Annex A.12 — Operations security — system hardening | Level 1 + Level 2 |
| FedRAMP | NIST 800-53 controls mapped to CIS benchmarks | Level 1 + Level 2 |
Audit Evidence
kube-bench output serves as audit evidence for compliance assessments:
# Generate JSON output for compliance tools
kube-bench run --json > cis-benchmark-$(date +%Y%m%d).json
# Generate human-readable report
kube-bench run > cis-benchmark-report-$(date +%Y%m%d).txt
Compliance teams expect:
- Baseline scan — Initial benchmark results when the cluster is provisioned
- Remediation evidence — Before/after scans showing failures were fixed
- Recurring scans — Scheduled kube-bench runs (weekly or per-deployment)
- Exception documentation — Justification for any accepted WARN or FAIL results
Example Benchmark Items in Detail
Let’s examine three representative benchmark items to understand the depth of each check.
Example 1: Check 1.2.1 — Anonymous Authentication
| Field | Value |
|---|---|
| ID | 1.2.1 |
| Description | Ensure that the --anonymous-auth argument is set to false |
| Level | 1 (Scored) |
| Component | API Server |
| Risk | Anonymous requests bypass all authentication; any network-adjacent attacker can query the API |
Audit:
# Check the API server process for the flag
ps -ef | grep kube-apiserver | grep anonymous-auth
# Or check the static Pod manifest
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep anonymous-auth
Remediation:
# In /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --anonymous-auth=false # Add or modify this flag
Example 2: Check 2.2 — etcd Client Certificate Auth
| Field | Value |
|---|---|
| ID | 2.2 |
| Description | Ensure that the --client-cert-auth argument is set to true |
| Level | 1 (Scored) |
| Component | etcd |
| Risk | Without client certificate authentication, any client can connect to etcd and read/write all cluster state |
Audit:
ps -ef | grep etcd | grep client-cert-auth
Remediation:
# In /etc/kubernetes/manifests/etcd.yaml
spec:
containers:
- command:
- etcd
- --client-cert-auth=true # Add or modify this flag
Example 3: Check 4.2.1 — Kubelet Anonymous Auth
| Field | Value |
|---|---|
| ID | 4.2.1 |
| Description | Ensure that the --anonymous-auth argument is set to false |
| Level | 1 (Scored) |
| Component | Kubelet |
| Risk | Anonymous kubelet access allows unauthenticated reads of Pod status, node metrics, and potentially exec into containers |
Audit:
# Check kubelet process
ps -ef | grep kubelet | grep anonymous-auth
# Or check kubelet config
cat /var/lib/kubelet/config.yaml | grep -A2 authentication
Remediation (in kubelet config.yaml):
# In /var/lib/kubelet/config.yaml
authentication:
anonymous:
enabled: false
webhook:
enabled: true
Then restart kubelet:
sudo systemctl restart kubelet
Key Takeaways
- CIS benchmarks are the standard — They define what a secure Kubernetes cluster looks like
- Levels matter — Level 1 is mandatory; Level 2 is for defense in depth
- Scored checks are exam-relevant — Focus your remediation on scored FAIL results
- Version matching is critical — Use the benchmark version that matches your Kubernetes version
- The CKS exam tests application — You need to run kube-bench and fix failures, not recite benchmark IDs
Practice Questions
Q1: What organization publishes the CIS Kubernetes Benchmark?
Show Answer
The Center for Internet Security (CIS) publishes the CIS Kubernetes Benchmark. It is a consensus-based security configuration guide developed by security practitioners and Kubernetes experts. The document is freely available from cisecurity.org.
Q2: What is the difference between Level 1 and Level 2 CIS benchmark checks?
Show Answer
Level 1 checks are essential security controls with minimal operational impact — they represent the baseline that every cluster should meet. Level 2 checks provide defense-in-depth and may affect cluster operations or performance. Level 2 builds on Level 1 and is recommended for production and compliance-sensitive environments.
Key distinction: Level 1 = “must have for any cluster,” Level 2 = “should have for production/compliance.”
Q3: Explain the difference between Scored and Not Scored CIS benchmark checks. Which is more relevant for the CKS exam?
Show Answer
Scored checks have clear pass/fail criteria and directly affect the compliance score — they must pass for the cluster to meet benchmark requirements. Not Scored checks are advisory recommendations that don’t affect the score and may require organizational context to evaluate.
For the CKS exam, scored checks are more relevant because the exam tasks involve identifying and fixing failures — and failures on scored checks are what kube-bench highlights as critical.
Q4: Which CIS benchmark section covers the API server, and what is one critical check in that section?
Show Answer
Section 1.2 covers the API Server. One critical check is:
- 1.2.1 — Ensure that the
--anonymous-authargument is set tofalse
This is a Level 1, Scored check. Without this setting, unauthenticated users can make anonymous requests to the API server, bypassing all RBAC controls. Other critical API server checks include ensuring --authorization-mode includes RBAC and that --audit-log-path is configured.
Q5: A compliance auditor asks you to prove your Kubernetes cluster meets CIS benchmark Level 1 requirements. What tool do you run, and what evidence do you provide?
Show Answer
Run kube-bench against all nodes:
# On control plane node
kube-bench run --targets master
# On worker nodes
kube-bench run --targets node
# Generate JSON for compliance tools
kube-bench run --json > cis-report-$(date +%Y%m%d).json
Provide the auditor with:
- kube-bench JSON/text reports showing PASS/FAIL/WARN results for all Level 1 checks
- Remediation evidence — before/after reports showing failures were fixed
- Exception documentation — justification for any accepted WARN or FAIL results
- Evidence of recurring scans — scheduled kube-bench runs proving continuous compliance
Next: Learn how to automate CIS benchmark scanning with kube-bench Setup →
| ← CIS Benchmarks | kube-bench Setup → |
