How to Pass CKS (Certified Kubernetes Security Specialist) in 2026: Complete Study Guide
CKS is the hardest Kubernetes certification — requires an active CKA and tests hands-on security hardening under time pressure. This guide covers all 6 domains, essential tools (Falco, OPA Gatekeeper, Trivy, AppArmor), and a 10-week study plan built on top of CKA knowledge.
The Certified Kubernetes Security Specialist (CKS) is the most demanding of the three CNCF Kubernetes certifications. Unlike the CKA and CKAD, CKS requires you to hold an active CKA before you can register — and its content assumes you are already comfortable with cluster administration. The exam does not test whether you can run a cluster; it tests whether you can harden one against real attack vectors, using tools like Falco, OPA Gatekeeper, Trivy, AppArmor, and Kubernetes native security primitives. If you underestimate it, you will fail with a solid Kubernetes background. This guide covers everything you need to approach CKS systematically.
Why CKS Is the Hardest Kubernetes Certification
Three factors combine to make CKS significantly harder than CKA:
- Security hardening under time pressure. CKS tasks require you to configure AppArmor profiles, write Falco rules, apply OPA Gatekeeper constraints, and tune audit logging — all in a live cluster with a 2-hour timer. These are not things you can wing.
- New tooling that has no equivalent in CKA. Falco, Trivy, Cosign, OPA Gatekeeper, and seccomp profiles are CKS-specific. Candidates who pass CKA and immediately attempt CKS without studying this tooling will fail the supply chain and runtime security tasks.
- The configuration details are unforgiving. A Falco rule in the wrong file is silently ignored. An AppArmor profile not loaded on the target node causes a pod to fail with an error. An OPA Gatekeeper constraint with
enforcementAction: auditinstead ofdenywill not block anything. The exam checks outcomes, not effort.
What CKA Knowledge Transfers to CKS
If you have a current CKA, you bring significant relevant knowledge into CKS. These skills transfer directly:
- RBAC — CKS goes deeper on RBAC hardening (least privilege, service account restrictions, role aggregation)
- NetworkPolicy — CKS uses it more aggressively for segmentation and egress control
- Static pod manifests at
/etc/kubernetes/manifests/— CKS tasks modify kube-apiserver flags here - kubectl proficiency — all the same command patterns apply
- Troubleshooting sequence — same node → control plane → kubelet order
What is new in CKS: supply chain security tools (Trivy, Cosign), runtime threat detection (Falco), policy enforcement (OPA Gatekeeper), Pod Security Standards, seccomp and AppArmor profiles, and Kubernetes audit logging.
The 6 CKS Domains
Domain 1: Cluster Setup (15%)
Focuses on securing the cluster's network perimeter and API access. Key topics and tools:
- NetworkPolicy — default-deny all ingress/egress; then explicitly allow only what is needed
- Ingress with TLS — TLS termination at Ingress, certificate management
- CIS Benchmark hardening — kube-apiserver flags:
--anonymous-auth=false,--authorization-mode=RBAC,Node,--audit-log-path,--encryption-provider-config - Secrets encryption at rest — EncryptionConfiguration resource; AES-CBC or AES-GCM providers
Domain 2: Cluster Hardening (15%)
Focuses on RBAC and service account controls. Key topics:
- RBAC — principle of least privilege; audit existing ClusterRoleBindings; remove cluster-admin where not needed
- Service account tokens — disable auto-mounting with
automountServiceAccountToken: falseat pod or ServiceAccount level; use projected volumes with expiry instead of long-lived tokens - API server access controls — NodeRestriction admission plugin; disabling insecure port
Domain 3: System Hardening (10%)
Focuses on OS-level security primitives. Key topics:
- AppArmor — load profiles with
apparmor_parser; apply to pods via annotations; verify withaa-status - seccomp —
RuntimeDefaultfor standard syscall filtering;Localhostfor custom profiles; applied viasecurityContext.seccompProfile - Reduce attack surface — disable unnecessary kernel modules; remove unused packages; restrict host path mounts
Domain 4: Minimize Microservice Vulnerabilities (20%)
Focuses on pod-level security controls and policy enforcement. Key topics:
- Pod Security Standards (PSS) — three levels: Privileged / Baseline / Restricted; applied as namespace labels
- OPA Gatekeeper — ConstraintTemplate with Rego policy; Constraint objects that enforce the template;
enforcementAction: denyto block vsauditto log - SecurityContext —
runAsNonRoot,readOnlyRootFilesystem,capabilities.drop: ["ALL"],allowPrivilegeEscalation: false - Secrets — prefer projected volumes over environment variables; rotate regularly
Domain 5: Supply Chain Security (20%)
Focuses on securing the container image pipeline. Key topics:
- Trivy — scan images for CVEs:
trivy image --severity CRITICAL,HIGH image:tag; scan filesystems; integrate into CI/CD - Cosign — sign images:
cosign sign --key cosign.key image:tag; verify signatures:cosign verify --key cosign.pub image:tag - ImagePolicyWebhook — enforce image policies at admission time; require signed or scanned images
- Dockerfile security — use non-root USER; multi-stage builds; minimal base images
Domain 6: Monitoring, Logging, and Runtime Security (20%)
Focuses on detecting threats in running clusters. Key topics:
- Falco — real-time syscall-based threat detection; custom rules; alert on privileged containers, shell spawns, file access
- Kubernetes audit logging — audit policy levels (None/Metadata/Request/RequestResponse); kube-apiserver flags; reading audit log output
- Behavioral anomaly detection — detecting container escapes, privilege escalation, unexpected network connections
10-Week CKS Study Plan
| Weeks | Focus | Activities |
|---|---|---|
| 1–2 | Refresh CKA + RBAC deep dive | Re-do CKA practice tasks; RBAC least privilege labs; NetworkPolicy default-deny exercises |
| 3–4 | Cluster hardening + Pod Security | kube-apiserver flags; service account token settings; Pod Security Standards enforcement; SecurityContext all fields |
| 5–6 | System hardening + OPA Gatekeeper | AppArmor profile loading and annotation; seccomp RuntimeDefault/Localhost; OPA Gatekeeper ConstraintTemplate writing in Rego |
| 7–8 | Supply chain + runtime security | Trivy scanning commands; Cosign sign/verify; Falco rule syntax; custom Falco rules; audit log policy writing |
| 9–10 | Full practice + killer.sh | Two full killer.sh sessions; timed task practice; review all error patterns from failed tasks |
killer.sh Strategy
Your CKS exam purchase includes two killer.sh simulator sessions. The killer.sh CKS simulator is intentionally harder than the actual exam — tasks are more complex, more numerous, and the time pressure is more severe. Do not be discouraged if you score 50-60% on your first attempt. The simulator's value is in exposing your weakest areas before you sit the real exam.
- Session 1 — Take it after completing weeks 7-8. Do not look at solutions until you have attempted every task. After finishing, read every solution explanation carefully, especially for tasks you did not complete.
- Session 2 — Take it during week 10, as a final timed rehearsal. Focus on the categories where you lost the most points in session 1.
Top Resources
- Killer Shell CKS course (included with exam purchase)
- Kubernetes documentation — kubernetes.io is the only reference allowed in the exam
- Falco documentation — falco.org for rule syntax reference
- OPA Gatekeeper library — github.com/open-policy-agent/gatekeeper-library for ConstraintTemplate examples
- Kim Wuestkamp's CKS course (Udemy) — comprehensive lab environment
Your CKA must be valid (not expired) at the time you register for CKS. CKA certifications are valid for 3 years. If your CKA is expired, you must renew it before purchasing CKS. Check your certification expiry at training.linuxfoundation.org before registering.
Comments
No comments yet. Be the first!
Comments are reviewed before publication.