Domain 1: Cluster Setup and Hardening

Overview

Cluster Setup and Hardening is the first and most foundational domain of the CKS exam. It accounts for 15% of the total exam weight and focuses on securing the Kubernetes cluster infrastructure itself -- from the API server and etcd to network policies and ingress configuration.

Exam Weight

This domain carries 15% of the CKS exam score. While not the heaviest domain, the concepts here underpin nearly every other security topic. A poorly hardened cluster makes all other security measures ineffective.

Topic Mindmap

What to Expect in the Exam

The CKS exam is performance-based, meaning you will work directly on live Kubernetes clusters. For this domain, expect tasks such as:

Task Type	Likelihood	Difficulty
Create/modify NetworkPolicy resources	High	Medium
Run kube-bench and fix findings	High	Medium
Configure encryption at rest for etcd	Medium	Hard
Set up or fix RBAC roles/bindings	High	Medium
Inspect and rotate TLS certificates	Medium	Medium
Harden API server flags	Medium	Hard
Configure secure ingress with TLS	Low-Medium	Medium

Time Management

You have 2 hours for the entire CKS exam. Cluster Setup and Hardening questions are often configuration-heavy. Practice editing static pod manifests and YAML files quickly -- you will not have time to look up every flag.

Key Tools and Commands

kube-bench

The primary tool for evaluating cluster security against CIS benchmarks.

# Run kube-bench on a control plane node
kube-bench run --targets=master

# Run kube-bench on a worker node
kube-bench run --targets=node

# Run specific checks
kube-bench run --targets=master --check=1.2.6

kubeadm

The cluster lifecycle tool with built-in certificate management.

# Check certificate expiration
kubeadm certs check-expiration

# Renew all certificates
kubeadm certs renew all

# View cluster configuration
kubeadm config view

kubectl for Network Policies

# List network policies
kubectl get networkpolicies -A

# Describe a specific policy
kubectl describe networkpolicy <name> -n <namespace>

# Apply a network policy
kubectl apply -f network-policy.yaml

etcdctl

# Check etcd health (with TLS)
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

Topics in This Domain

#	Topic	Key Focus
1	Network Policies	Default deny, ingress/egress rules, namespace isolation
2	CIS Benchmarks	kube-bench, interpreting results, remediation
3	TLS & Certificates	PKI architecture, rotation, etcd TLS
4	API Server Hardening	AuthN, AuthZ, admission controllers, audit logging
5	RBAC Deep Dive	Dangerous permissions, least privilege, service accounts
6	etcd Security	Encryption at rest, TLS, backup/restore
7	Ingress Security	TLS termination, security headers
8	Practice Questions	20 hands-on questions covering all topics
9	Solutions	Step-by-step solutions with explanations

Study Strategy

Recommended Approach

1. Start with Network Policies -- they appear frequently and are heavily tested
2. Master RBAC -- it intersects with almost every other security domain
3. Practice kube-bench -- know how to run it and fix the top findings
4. Understand the API server -- its flags control most security features
5. Be comfortable editing static pod manifests in /etc/kubernetes/manifests/

Common Mistakes

• Forgetting to restart the API server after changing its manifest (kubelet handles this automatically for static pods, but you must wait)
• Applying a NetworkPolicy to the wrong namespace
• Confusing Role/ClusterRole with RoleBinding/ClusterRoleBinding scope
• Not specifying both --cert and --key when using etcdctl