CKS — Kubernetes Security Specialist
The Certified Kubernetes Security Specialist (CKS) is the one Kubernetes certification you cannot walk up to cold: it requires an active CKA before the CNCF will even let you register. Once you're in, it's performance-based like the CKA — real clusters, a remote terminal, no multiple choice — but pointed entirely at security instead of general operations: hardening the cluster and the host underneath it, catching an attacker mid-attack with runtime detection, and closing the supply-chain path that let a bad image get scheduled in the first place. For this course, it's the credential that sits closest to security's overlap with reliability — a compromised cluster isn't "up" in any sense an SLO cares about, and the CKS is the hands-on proof that you can keep it from getting there. Below: what it actually tests, real logistics you should verify yourself, and whether it belongs on your study list this year.
Imagine two badges for looking after a treehouse. One badge — the CKA — says "I can build this treehouse, fix the ladder, and keep the pulley system running." You have to earn that one first. The second badge, the CKS, says something harder: "I can stop someone from sneaking in." Which knots to check before letting a delivery up the rope, which rooms each kid is allowed into, and how to notice — while it's happening, not the next morning — that someone's already inside who shouldn't be. Nobody hands you the second badge without proving you can run the treehouse first.
What the CKS is, and the one thing you need before you can sit it
☺ Like you're 10: It's a real hands-on test on real clusters, and you're not allowed to sign up unless you already passed the CKA first.
The CKS is issued jointly by the CNCF and the Linux Foundation, and like its sibling exams it is performance-based: no question bank, no A/B/C/D. You're dropped into a remote Linux terminal with a handful of pre-built clusters and given tasks — restrict a namespace with a default-deny NetworkPolicy and re-open exactly one path, find the container image carrying a critical CVE before it reaches a permitted registry, read a runtime alert and identify which container just spawned an unexpected shell. Grading is on the resulting cluster state, the same as the CKA, which means an unverified fix is functionally the same as no fix — running kubectl get or its equivalent after every change is not optional discipline, it's how you pass.
The prerequisite that makes this exam different
Here's the detail that catches people out: the CKS requires a current, active CKA certification to register. It is the only exam in the whole Kubernetes certification family with a formal, enforced gate — KCNA, CKAD, and the CKA itself have none. The reasoning is fluency, not gatekeeping for its own sake: every CKS task assumes you can already switch contexts, edit a static Pod manifest on a control-plane node, and read a component's logs without stopping to remember the command. If your CKA has lapsed, the practical move is to renew it before you book the CKS — treat the two as a pair, not two independent line items on a study plan.
Who it's actually built for
It targets people who already operate Kubernetes and are now responsible for keeping it safe from something more deliberate than a bad deploy: SREs and platform engineers who own cluster guardrails, security engineers moving into cloud native who already think in threat models and need the Kubernetes-specific mechanics, and anyone whose on-call rotation includes "is this alert an attacker or a false positive." It assumes the CKA's Linux and cluster-operations fluency as a floor, not a stretch goal.
The six official domains — and the three pillars they group into
☺ Like you're 10: Six named topics on the official syllabus, but they really cluster into three bigger ideas: lock it down, watch the supply chain, and catch what gets through anyway.
The CNCF publishes six weighted domains for the CKS curriculum, and they sum to exactly 100%. Grouped loosely, they map onto the three things this page keeps coming back to — cluster and workload hardening, supply-chain security, and runtime security — with hardening claiming the largest combined share.
Add Cluster Setup, Cluster Hardening, System Hardening, and Minimize Microservice Vulnerabilities together and hardening work — network policy, RBAC, Pod Security Standards, kernel-level confinement — accounts for roughly 60% of the exam on its own. Supply Chain Security and Monitoring/Logging/Runtime Security carry 20% each, and together are the newest-feeling material to anyone coming from a pure-operations background: most cluster administrators have configured RBAC, far fewer have wired an admission controller to reject unsigned images or written an audit policy from scratch.
What you actually need to be able to do
☺ Like you're 10: Here's the real substance behind each pillar — the files you edit and the commands your fingers need to know without pausing to think.
Cluster & workload hardening
The default posture for a NetworkPolicy is worth knowing cold: policies are additive and allow-only, selecting a Pod with any policy flips it to deny-by-default for that direction, and an egress rule that doesn't explicitly permit DNS on UDP/53 breaks every name lookup the moment it applies. Pod Security Admission is the other half — three standards (privileged, baseline, restricted) applied as namespace labels, in three modes (enforce rejects, audit logs, warn messages the caller), with restricted requiring a non-root user, no privilege escalation, a dropped ALL capability set, and a seccomp profile.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: checkout
spec:
podSelector: {} # every pod in the namespace
policyTypes: [Ingress, Egress] # deny both directions once this applies
---
apiVersion: v1
kind: Namespace
metadata:
name: checkout
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
---
apiVersion: v1
kind: Pod
metadata:
name: api
namespace: checkout
spec:
automountServiceAccountToken: false # no API token mounted unless the workload needs one
securityContext:
runAsNonRoot: true
seccompProfile: { type: RuntimeDefault }
containers:
- name: api
image: registry.internal/checkout-api@sha256:9f2c... # digest, not a mutable tag
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities: { drop: ["ALL"] }Underneath both sits RBAC and the host itself: Role versus ClusterRole, the reflex of kubectl auth can-i to prove a change actually landed, disabling the default ServiceAccount token mount on anything that doesn't call the API, and trimming the node's own attack surface — closed ports, least-privilege cloud IAM on the node role, and kernel-level confinement with seccomp and AppArmor. Kubernetes reliability patterns covers the same substrate from the availability side; this is the same terrain, examined for who can reach it.
Supply-chain security
Walk the pipeline end to end rather than memorizing it as separate facts: scan an image for known CVEs, generate an SBOM, statically analyze the manifest itself, sign the artifact, and then make the cluster refuse anything that skipped a step. A Kubernetes Secret is base64, not encryption — treat it accordingly.
# scan and fail the build on anything high or critical trivy image --severity HIGH,CRITICAL --exit-code 1 registry.internal/checkout-api:2.1.0 # sign keylessly, then verify with an identity constraint — # a wildcard identity accepts anyone's signature, which defeats the point cosign sign registry.internal/checkout-api@sha256:9f2c... cosign verify --certificate-identity-regexp '^https://github\.com/acme/.+' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ registry.internal/checkout-api@sha256:9f2c...
Enforcement lives at admission — a policy engine checks the registry an image came from and whether its signature verifies, and rejects the Pod before the scheduler ever sees it. Production readiness reviews is where this connects back to the rest of the course: a service that hasn't wired signature verification into its deploy path shouldn't clear the review, the same way a service with no dashboard shouldn't.
Runtime security & detection
Prevention fails eventually, which is why the last piece is watching what happens after something gets through. A runtime security tool watches syscalls and fires on behavioral rules — a shell spawned inside a container, a process reading a credentials file it's never touched before — and audit logging captures who did what to the API server, at a level you choose per resource type (secrets get metadata only; RBAC changes get the full request and response).
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata # who touched it, never the payload
resources: [{ group: "", resources: ["secrets"] }]
- level: RequestResponse # RBAC changes are the classic escalation path — log the full object
resources: [{ group: "rbac.authorization.k8s.io", resources: ["roles", "rolebindings"] }]
- level: Metadata # everything else, at minimum
This is where the CKS overlaps most directly with what this course already teaches about incidents: reading a runtime alert and naming the phase of attack you're looking at is the same muscle as incident management and on-call asks for when an SLO starts burning — orient first, act second, and don't guess when you can verify. And once the incident is over, blameless postmortems apply just as directly to "an attacker got a shell in our payments namespace" as they do to "a bad deploy took down checkout." Foxy's five-whys doesn't care whether the root cause was a bug or an adversary.
A cluster an attacker has quietly compromised is not "up" in any sense an SLO cares about, even while every health check is green. Security's overlap with reliability is the deep dive that makes this argument in full; the CKS is the hands-on proof that you can act on it — not just agree with it in a design review.
Exam logistics — verify every number before you book
☺ Like you're 10: Here's the shape of the test as it's generally published — but prices, timings, and rules change, so read the official page before you pay.
Some things about the CKS are structural and unlikely to move. Others — price, duration, cut score, retake policy, certification validity — are exactly the kind of detail the Linux Foundation revises without much announcement, and this page's numbers were last checked in 2026. Confirm anything below on the vendor's own page before you register.
| Item | What is generally published |
|---|---|
| Provider | CNCF & The Linux Foundation |
| Format | Performance-based — hands-on tasks on live, remote clusters. No multiple choice. |
| Delivery | Online, remotely proctored, with a webcam room scan and photo ID check |
| Prerequisite | A current, active CKA — checked at registration, not just recommended |
| Duration | Historically around 2 hours |
| Domains | Six weighted domains as tabulated above, summing to 100% |
| Passing score | Not consistently published — verify the current cut score at the vendor's page |
| Price | Historically in the same few-hundred-dollar band as the CKA and CKAD — confirm current pricing and any bundle discount |
| Retake | Registration has historically included one free retake |
| Validity | Historically 2 years from the date you pass — the Linux Foundation has revised validity terms across the Kubernetes certification line before, so check what your specific purchase includes |
| Permitted documentation | A published allowlist — historically the Kubernetes docs plus a short list of named security-project docs. It is wider than the CKA's but still an allowlist, not the open internet. Read the exam's Important Instructions for the current list. |
| Kubernetes version | The environment and curriculum both track a specific recent release — confirm the version before you study task specifics |
Price, duration, pass mark, retake policy, the CKA-currency check, and the permitted-documentation list all move without much notice, and this is an independent, unofficial course. Verify current details on the official Linux Foundation CKS page and the CNCF certification page before you register, and re-download the curriculum from github.com/cncf/curriculum — if it disagrees with the table above, it's right and this page is stale.
↗ Official CKS page — Linux Foundation ◆ CNCF certification page
Who should consider it — and who should wait
☺ Like you're 10: Great fit if you already own the guardrails and just passed the CKA. Not the right next step if you haven't cleared that gate yet, or if security on Kubernetes genuinely isn't your job.
The case for taking it
Take it if you already hold a current CKA and any of the following describe your work: you own or influence the NetworkPolicies, RBAC bindings, and admission rules a platform's tenants inherit; your on-call rotation has ever included a runtime security alert you weren't sure how to read; or you want the hands-on complement to the ideas in security's overlap with reliability rather than just the argument for why they matter. It's also a reasonable next step after chaos engineering — Rocky's whole job is opening whatever was latched shut, and the CKS is the credential for the person who has to have latched it correctly in the first place.
When to wait or skip
Wait if you don't yet hold a current CKA — that's not a soft recommendation, it's the registration gate, so the real cost of skipping ahead is sitting (and paying for) two exams instead of planning them as a pair. Skip it, at least for now, if security on Kubernetes genuinely isn't your role — if a dedicated security team owns hardening and runtime detection end to end and your SRE work is SLOs, error budgets, and capacity, the depth here won't show up in your day-to-day for a while. And skip it if you're new to Kubernetes altogether: the CKS assumes CKA-level fluency as a floor, and trying to learn cluster basics and security hardening at the same time under exam pressure is a bad way to learn either one.
How to prepare using this site
☺ Like you're 10: This course wasn't built as CKS prep, but several pages already cover real chunks of it — here's the map.
| CKS pillar | Study here |
|---|---|
| Cluster & workload hardening Cluster Setup, Cluster Hardening, System Hardening, Minimize Microservice Vulnerabilities | Kubernetes reliability patterns for the substrate itself · Reliability patterns for the guardrail mindset Timmy teaches |
| Supply-chain security | Production readiness reviews for where a signature check belongs in the release gate · Release engineering & progressive delivery for the pipeline it plugs into |
| Runtime security & detection | Monitoring & observability for the telemetry underneath an alert · Incident management & on-call for responding to one · Blameless postmortems for writing it up afterward |
| The adversarial mindset | Chaos engineering — Rocky's whole discipline is finding what a hardening control missed, which is exactly what the CKS's "identify the phase of attack" competency asks of you |
| The prerequisite itself | CKA — read this first if it isn't already current |
| Full-course credential | SRE Practitioner for the discipline broadly, if security specifically isn't your gap |
On a throwaway cluster, run the whole loop once. (1) Label a namespace pod-security.kubernetes.io/enforce=restricted and try to deploy a privileged Pod — read the rejection message; it names every rule you broke. (2) Fix it: non-root, dropped capabilities, a seccomp profile, a read-only root filesystem. (3) Apply a default-deny NetworkPolicy, confirm with an exec into another Pod that traffic now hangs, then re-open exactly one port. (4) Scan an old image like nginx:1.14 for CVEs and count the criticals. (5) Now write the incident as if it were real: a Pod without your new controls got exploited — walk it through this course's own postmortem template. Five steps, one afternoon, and the exam stops being abstract.
Rocky the Raccoon: I got into the checkout namespace through a Pod that still had its default ServiceAccount token mounted. Nobody told it not to trust visitors.
Timmy the Turtle: That's exactly the competency I keep telling people about — disable the default token mount unless a workload actually calls the API. It's one line, and almost nobody sets it.
Foxy: So walk me through it like a postmortem. What was the first sign, and what phase of the attack were we in when we caught it?
Rocky: Reconnaissance first — I listed what the stolen token could reach. You caught me at the second phase, when I tried to actually read a Secret with it.
Foxy: Because the audit policy logged the request at full detail for anything touching RBAC or secrets. That's not luck, that's a policy someone wrote on purpose.
Timmy: Which is the whole CKS in one sentence — harden it so the token isn't there to steal, and watch it closely enough that if one slips through, you catch it before it matters.
Pair this page with CKA for the prerequisite and security's overlap with reliability for the argument underneath why any of this belongs in an SRE's certification plan at all. Full comparisons against every other certification on this site live on the certifications hub.
1. What is the one formal prerequisite for the CKS, and how is that different from every other exam in the Kubernetes family? 2. Name the six official CKS domains and their weights, and which four group into "hardening." 3. What does a NetworkPolicy with an empty podSelector and both policy types listed actually do? 4. Give the three Pod Security Standards and the three modes they can be applied in. 5. Why does disabling the default ServiceAccount token mount matter for runtime security specifically? 6. Name one situation where an SRE should wait before sitting the CKS.
Check your answers
- A current, active CKA certification, checked at registration — the CKS is the only exam in the Kubernetes family with a formal, enforced prerequisite; KCNA, CKAD, and the CKA itself have none.
- Cluster Setup 15%, Cluster Hardening 15%, System Hardening 10%, Minimize Microservice Vulnerabilities 20%, Supply Chain Security 20%, Monitoring, Logging and Runtime Security 20%. The first four — Cluster Setup, Cluster Hardening, System Hardening, and Minimize Microservice Vulnerabilities — group into "hardening," roughly 60% of the exam combined.
- It selects every Pod in the namespace and, with
policyTypes: [Ingress, Egress]and no rules listed, denies all ingress and egress traffic for them — the default-deny baseline you then re-open selectively. - Standards: privileged, baseline, restricted. Modes: enforce (reject), audit (record in the audit log), warn (message the caller at apply time).
- A mounted ServiceAccount token is a live API credential sitting in the container's filesystem. If an attacker gets a shell, an unnecessary mounted token hands them a working credential for free — disabling the default mount removes that credential from workloads that never needed to call the API in the first place.
- Any reasonable answer, e.g.: you don't yet hold a current CKA (the registration gate isn't optional); a dedicated security team already owns hardening and runtime detection end to end and it isn't your role; or you're new to Kubernetes and haven't built CKA-level fluency yet.