CKS Track
The Certified Kubernetes Security Specialist exam tests whether you can harden a cluster and its workloads and investigate a compromise. It requires a passed CKA and assumes that level of speed. Most tasks involve a tool outside core Kubernetes (Falco, Trivy, kube-bench, AppArmor) or editing control plane static Pod manifests, so the exam rewards hands-on tool practice far more than reading.
Exam format, shell setup and time management are in the Certifications hub. This page covers what to study.
| Domain | Weight | Practice in this wiki |
|---|---|---|
| Cluster Setup | 15% | Lab + practice for NetworkPolicy; guided labs for the CIS benchmark, Ingress TLS and metadata |
| Cluster Hardening | 15% | Lab + practice for RBAC and ServiceAccounts; guided labs for API access |
| System Hardening | 10% | Guided labs for seccomp and host footprint; AppArmor not run; host IAM is reading only |
| Minimize Microservice Vulnerabilities | 20% | Lab + practice for Pod Security; guided labs for Secrets encryption, sandboxing and encryption in transit |
| Supply Chain Security | 20% | Guided labs; signature verification at admission is a gap |
| Monitoring, Logging and Runtime Security | 20% | Guided labs for Falco, audit logging and immutability; one unguided investigation |
The third column says what kind of practice exists, using the labels defined in the hub. It is not a readiness score. Most CKS labs are still guided: they show a control working once. Only CKS-01, CKS-13 and CKS-14 have unguided tasks with checks.
Objectives are summarised from the Linux Foundation CKS page and curriculum as checked on 2026-10-13 (exam on Kubernetes v1.35; this wiki’s baseline is 1.37).
Which version each CKS lab was run on
CKS-01, CKS-13 and CKS-14 were run on Kubernetes v1.37.0 on 2026-10-13. CKS-02 to CKS-12 were run earlier on kind v0.31 with Kubernetes v1.35.0, which is the version the exam used on the check date, and have not been re-run on v1.37. Expect small differences in output on v1.37, and note that kind v0.33 or newer is needed for it. Each lab’s header states its own test environment.
Where the labs run
Most CKS labs run on the
kindcluster from Lab CKAD-01 and reach the node withdocker execin place ofssh. They edit the API server manifest repeatedly, so take the backup each lab asks for, and note that several labs write that backup to the same path: the copy is a safety net for the lab you are in, not a way back to an earlier lab. Run one CKS lab at a time and finish its cleanup before starting the next; if a lab leaves the API server unhealthy, recreate the cluster as Lab CKAD-01 describes. Lab CKS-04 changes how Secrets are stored and cannot be undone by restoring a manifest alone. Lab CKS-09 and Lab CKS-11 create their own clusters, which changes your kubectl context; runkubectl config use-context kind-k8s-labafterwards. They also need more memory than the other labs. AppArmor needs a virtual machine node.
Prerequisites
- A passed CKA, or the CKA Track completed, including editing static Pod manifests and recovering when the API server does not come back.
- L07 Security and Security Overview for the layered model the domains follow.
- Security refresher as a quick self-check.
- Linux security primitives: Capabilities, seccomp, AppArmor and Container Security.
1. Cluster Setup (15%)
| Objective | Read | Practise |
|---|---|---|
| Use network security policies to restrict cluster-level access | NetworkPolicy, Network Policies (Security) | Lab CKS-01, Lab CKS-11 |
| Use the CIS benchmark to review component configuration | Compliance Frameworks, Cluster Hardening, Node Hardening | Lab CKS-02 |
| Properly set up Ingress with TLS | Ingress, TLS and mTLS | Lab CKAD-09 |
| Protect node metadata and endpoints | Security Baseline, Node Hardening | Lab CKS-11 |
| Verify platform binaries before deploying | Covered in the lab | Lab CKS-07 |
Task drills
- Write a default-deny policy for a namespace, then allow one tier to reach another on a single port and nothing else.
- Block Pod egress to the cloud metadata address
169.254.169.254with anipBlockandexcept, while leaving other egress open. - Run
kube-benchagainst a control plane node, pick three failed checks for the API server, kubelet and etcd, and fix each one. - Create a TLS Secret from a certificate and key, and serve an Ingress host over HTTPS with it.
- Download a Kubernetes release binary, compare its
sha512sumwith the published checksum, and say whether the binary on the node matches.
2. Cluster Hardening (15%)
| Objective | Read | Practise |
|---|---|---|
| Use RBAC to minimize exposure | RBAC, RBAC (Security) | Lab CKS-01, Lab CKS-13 |
| Exercise caution in using service accounts | Service Accounts | Lab CKS-01, Lab CKS-13 |
| Restrict access to the Kubernetes API | Authentication vs Authorization, Cluster Hardening, Admission Controllers, Certificates | Lab CKS-02, Lab CKS-08 |
| Upgrade Kubernetes to avoid vulnerabilities | Upgrade Strategy | Lab CKA-04 |
Task drills
- Audit an over-permissive Role (wildcards,
secretsaccess,escalateorbind) and reduce it to the verbs a workload actually uses. - Find every subject bound to
cluster-adminand remove one that should not be. - Disable token automounting on the
defaultServiceAccount of a namespace, and give one workload a dedicated ServiceAccount with a short-lived projected token. - Turn off anonymous authentication on the API server and confirm the
NodeRestrictionadmission plugin andNode,RBACauthorization modes are set. - Stop a Service from exposing the API server through a NodePort, and confirm the insecure and profiling endpoints are off.
- Upgrade a cluster by one patch version to pick up a fix, control plane first.
3. System Hardening (10%)
| Objective | Read | Practise |
|---|---|---|
| Minimize host OS footprint | Node Hardening, Linux CIS Hardening, systemd Service Hardening | Lab CKS-12 |
| Use least-privilege identity and access management | PAM, OIDC Integration | Reading only |
| Minimize external access to the network | iptables, firewalld, ss, Ports | Lab CKS-12 |
| Use kernel hardening tools such as AppArmor and seccomp | Seccomp and AppArmor, AppArmor, seccomp, sysctl | Lab CKS-05 (seccomp run; AppArmor not run) |
Task drills
- On a node, list listening sockets with
ss -tlnp, identify a service that should not be running, stop and disable it, and remove its package. - Find the process bound to a given port and the binary behind it.
- Load an AppArmor profile on a node with
apparmor_parser, confirm it withaa-status, and apply it to a container throughsecurityContext.appArmorProfile. - Place a custom seccomp profile under the kubelet’s seccomp directory and reference it from a Pod with type
Localhost. Then switch another Pod toRuntimeDefault. - Prevent a kernel module from loading by blacklisting it.
4. Minimize Microservice Vulnerabilities (20%)
| Objective | Read | Practise |
|---|---|---|
| Use appropriate Pod Security Standards | Pod Security Standards, SecurityContext, Pod Security (Security) | Lab CKS-01 |
| Manage Kubernetes Secrets | Secrets, Secret Encryption, etcd Encryption, Secrets (Security) | Lab CKS-04 |
| Understand and implement isolation techniques | Runtime Sandboxing, Multi-Tenancy | Lab CKS-10 |
| Implement Pod-to-Pod encryption | Networking Deep Dive, Istio, TLS and mTLS | Lab CKS-11 |
Policy engines appear in tasks as something already installed that you must read and adjust, so know OPA and Gatekeeper and Kyverno well enough to edit a constraint or policy.
Task drills
- Label a namespace to enforce the
restrictedPod Security Standard, then fix a Deployment until it is admitted. - Find every Pod in a cluster that runs privileged, as root, or with a
hostPath, and remediate or delete as the task directs. - Write an
EncryptionConfigurationfor Secrets, wire it into the API server manifest with the flag and a volume mount, re-encrypt existing Secrets, and prove it by reading the raw key from etcd withetcdctl. - Read a Secret straight out of etcd to show that it was stored unencrypted.
- Create a RuntimeClass for gVisor (
runsc) and run a Pod with it; confirm fromdmesginside the Pod that it is sandboxed. - Fix a Gatekeeper constraint or Kyverno policy so that it rejects images from an untrusted registry.
- Enable transparent encryption between Pods with Cilium and prove it from a packet capture. Encryption gives confidentiality on the wire.
- Separately, read how a CiliumNetworkPolicy requires mutual authentication. That proves the identity of the peer and is a different control from encryption; one does not imply the other.
5. Supply Chain Security (20%)
| Objective | Read | Practise |
|---|---|---|
| Minimize base image footprint | Image Hardening, Dockerfile Best Practices, Images and Layers | Lab CKS-07 |
| Understand your supply chain (SBOM, CI/CD, artifact repositories) | SBOMs, CD Integration, Registries | Lab CKS-07 |
| Secure your supply chain (permitted registries, signing) | Admission Controllers, Kyverno, SBOMs (cosign) | Lab CKS-08, Lab CKS-09 |
| Perform static analysis of workloads and images | Vulnerability Scanning, Image Hardening | Lab CKS-07 |
Task drills
- Rewrite a Dockerfile as a multi-stage build on a minimal base, with a non-root
USER, a pinned tag and no secrets in layers. - Scan the images of every Pod in a namespace with
trivy image, and delete the Pods whose images haveCRITICALvulnerabilities. - Generate an SBOM for an image in SPDX or CycloneDX format, and find which image in a set contains a given package version.
- Configure the
ImagePolicyWebhookadmission plugin: admission configuration file, kubeconfig for the backend,defaultAllow: false, the API server flags and the volume mount. - Restrict a namespace to images from one registry using a policy engine or a
ValidatingAdmissionPolicy. - Review a Pod manifest and a Dockerfile by eye and with a scanner (
kubesec scan, KubeLinter), and fix the two worst findings in each.
6. Monitoring, Logging and Runtime Security (20%)
| Objective | Read | Practise |
|---|---|---|
| Perform behavioural analytics to detect malicious activity | Runtime Detection (Falco, Tetragon) | Lab CKS-06 |
| Detect threats across infrastructure, apps, networks and workloads | Runtime Detection, auditd, Kubernetes Security | Lab CKS-06, Lab CKS-03 |
| Investigate and identify phases of attack and bad actors | Assume Breach Principle, kubectl Debug Toolkit | Lab CKS-06, Lab CKS-03, Lab CKS-14 (unguided) |
| Ensure immutability of containers at runtime | SecurityContext | Lab CKS-05 |
| Use Kubernetes audit logs to monitor access | Audit Logging | Lab CKS-03 |
Task drills
- Read Falco output on a node (
journalctl -u falcoor its log file), identify which Pod spawned a shell or wrote under/etc, and scale its Deployment to zero. - Change the output format of an existing Falco rule to include specific fields, and override a rule in the local rules file instead of editing the default one.
- Find the container running an unexpected process using
crictl ps,crictl inspectand the process ID on the node. - Make a container immutable: read-only root filesystem,
emptyDironly for the paths that must be writable, no privilege escalation. - Write an audit policy that logs Secrets at
Metadata, a named namespace atRequestResponseand drops everything else, then enable it on the API server with log path, max age, max backups and the two volume mounts. - From an audit log, find who deleted a given Secret and when.
Gaps in the wiki
| Objective | What is missing | Use instead |
|---|---|---|
| AppArmor | Lab CKS-05 includes it, but that section was not run because kind nodes do not expose AppArmor | Run the section on a virtual machine node, and pin the Pod to the node where the profile is loaded |
| Signature verification at admission | Lab CKS-09 signs and verifies with the CLI and enforces digests. A digest policy admits an unsigned image; no lab makes the cluster check signatures | Kyverno verifyImages |
| A working ImagePolicyWebhook backend | Lab CKS-08 configures the plugin with no backend, which proves the fail-closed path only, not TLS, the ImageReview exchange or an allow/deny decision | ImagePolicyWebhook |
| Cilium mutual authentication | Lab CKS-11 covers encryption; authentication.mode: required needs SPIRE and is not practised | Cilium mutual authentication |
| Least-privilege identity and access management | Host and cloud IAM are reading only. Kubernetes RBAC is covered by Lab CKS-13 | OIDC Integration |
| Investigation with detection tooling | Lab CKS-14 investigates from API and node evidence only. No lab correlates audit-log and Falco evidence for an unknown actor | Repeat Lab CKS-14 on a cluster with Lab CKS-03’s audit policy enabled |
| Unguided practice for CKS-02 to CKS-12 | These labs are guided walk-throughs with no independent task or check | The CKS practice set and the domain drills |
| Re-run on Kubernetes v1.37 | CKS-02 to CKS-12 were last run on v1.35.0 | Run them on a v1.35 cluster, which matches the exam, or expect minor output differences |
| Independent grading | The practice tasks give checks you run yourself; nothing scores you automatically | The exam simulator, if your registration includes it |
Study plan
The plan below is a revision schedule for someone with a recent CKA, at about an hour a day. It does not include provisioning a virtual machine for AppArmor. Finishing it is not a pass prediction.
| Week | Focus | Practice |
|---|---|---|
| 1 | L07 overview, domain 2 (RBAC, ServiceAccounts, API access) | Lab CKS-01, Lab CKS-13, domain 2 drills |
| 2 | Domain 1 (NetworkPolicy, CIS benchmark, Ingress TLS) | Lab CKS-02, Lab CKAD-09 |
| 3 | Domain 4 (Pod Security Standards, Secrets encryption, sandboxing, policy engines) | Lab CKS-04, Lab CKS-10, Lab CKS-11 |
| 4 | Domain 3 (AppArmor, seccomp, host footprint), domain 5 (images, Trivy, SBOM, admission) | Lab CKS-05, Lab CKS-12, Lab CKS-07, Lab CKS-08, Lab CKS-09 |
| 5 | Domain 6 (Falco, audit logging, immutability, investigation) | Lab CKS-03, Lab CKS-06, Lab CKS-14 |
| 6 | The timed practice set, weak spots, the simulator sessions if you have them | CKS practice set |
Ready when
- You can edit the API server manifest, add a flag with its volume and mount, and recover promptly when the API server fails to restart, using
crictland the container’s log to find the mistake. - You can write an audit policy and an
EncryptionConfigurationstarting from the documentation page, and verify each from evidence: a log entry, a ciphertext prefix in etcd. - For every control you apply, you can name one request that must still succeed and one that must now fail, and you test both.
- You know where each tool keeps its configuration and output on a node: Falco rules, AppArmor profiles, seccomp profiles, audit logs.
- You finish the CKS practice set inside two hours at or above the pass mark, using only the sites the CKS allows.
- If you have the simulator, your second session is at or above the pass mark.
Further reading
- CKS curriculum
- CKS exam page
- Securing a cluster
- Falco documentation
- Trivy documentation
- CIS Kubernetes Benchmark
Across the wiki
- CKA Track: the prerequisite exam.
- CKAD Track
- Kubernetes Security: the security domain’s view of the same topics.
- Zero Trust
- EKS Security: how these controls map onto a managed cluster.