CKS — Certified Kubernetes Security Specialist

The Certified Kubernetes Security Specialist (CKS) is the hardest of the core Kubernetes certifications and the only one requiring you to already hold another. It is performance-based — you are dropped onto live clusters and told to harden them — spanning CIS benchmarks and node metadata, Pod Security Standards, seccomp and AppArmor, signed images and SBOMs at admission, and catching an attacker at runtime with Falco and audit logs. For a platform engineer that is the guardrail half of the job, examined far deeper than the CNPE goes. Here’s what it covers, whether it’s worth your money, and how to study for it on this site.

What the CKS is — and who it is for

☺ Like you’re 10: It’s a hands-on test — about two hours, going by past sittings — where you fix real security problems on real clusters, and you’re only allowed to sit it if you already passed the CKA.

The CKS is a performance-based exam from the CNCF and The Linux Foundation — no multiple choice. You get a remote Linux desktop, a set of clusters, and a list of tasks: restrict this namespace with a NetworkPolicy, fix this over-permissive Role, make this Pod run unprivileged with a seccomp profile, find the image with the critical CVE, turn on audit logging with the right policy, read the Falco alert and stop the workload that caused it. You are graded on the resulting cluster state, not how you got there. Where the CKA asks “can you operate a cluster?”, the CKS asks “can you operate one an attacker is actively interested in?” — and expects you to know the difference between a control that looks secure and one that closes the path.

The one hard prerequisite — an active CKA

This is the detail that catches people out. The CKS is the only exam in the Kubernetes family with a formal gate: you must hold a current, non-expired CKA to sit it. Not “it helps” — it is checked. If your CKA has lapsed, you renew or re-sit it first, so plan the two as a pair. The gate exists because CKS assumes fluency: every task presumes you can already switch contexts, edit a static Pod manifest on a control-plane node, and restart a component and read its logs without thinking. The clock does not allow for re-learning kubectl.

Who it actually suits

• Platform engineers who own the guardrails — if admission policy, tenancy boundaries and image provenance are yours, this is your syllabus written down.
• SREs and cluster administrators already holding a CKA who want the security half of the job formalised.
• Security engineers moving into cloud native — fluent in threat models and IAM, needing the Kubernetes-specific mechanics.
• Consultants and contractors, where a security credential is often a procurement checkbox before you’re allowed near production.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: It makes you genuinely better at the “keep everyone safe” part of building a platform. But it doesn’t teach you how to build the platform itself, so don’t take it instead of the thing you actually need.

Be honest about the overlap. The CNPE’s Security & Policy Enforcement domain is 15% of that exam; the CKS is 100% security at roughly three times the depth, on the substrate your platform sits on. Everything transfers: the NetworkPolicy you write for the CKS is the one your tenants inherit from the golden path, and the Kyverno rule that verifies signatures is the one that keeps unvetted images off the cluster.

What it gives you that the CNPE does not

Three things. The host and kernel layer — seccomp, AppArmor, gVisor and Kata, trimming the host OS footprint; platform courses gesture at this, the CKS makes you configure it. Attacker perspective — the curriculum explicitly asks you to identify phases of an attack, which reframes every guardrail as “what does this actually stop?” And supply chain end to end — SBOMs, permitted registries, signing and validating artifacts, static analysis: the part of platform engineering most teams do worst, and a full 20% here.

When to skip it

Defer it if any of these hold. You don’t hold a CKA and don’t want one — the prerequisite isn’t negotiable, so the real cost is two exams. Your platform work sits above the cluster — if your days go to Backstage templates, Crossplane compositions and developer experience, the kernel-hardening and CIS material will be interesting and largely unused; the CNPA → CNPE line fits better. You need breadth this quarter — CKS is a narrow, expensive spike, so if your gaps are observability, delivery and platform APIs, fill those first. And if you’re chasing a badge rather than a skill, this is the worst one to chase: hands-on, hard, and it does not reward cramming.

The official domains and their weights

☺ Like you’re 10: The test is split into six parts, and they’re not equal. Three of them are worth twenty points each — that’s where most of your marks live.

These are the six domains and weights exactly as published in the CNCF’s CKS Exam Curriculum (the copy studied here is v1.34). Nothing below is paraphrased or re-weighted, and the six weights sum to 100% — 15 + 15 + 10 + 20 + 20 + 20. The curriculum is versioned against a Kubernetes release, so download the current one from the official CNCF curriculum repository before you revise; if the copy you download disagrees with the table below, it is right and this page is stale.

Every competency, domain by domain

And here is the full list of competencies under each domain, transcribed from the same curriculum document:

Reading the shape of the blueprint

Two things jump out. First, the three 20% domains — microservice vulnerabilities, supply chain, and monitoring/runtime — are 60% of the exam between them, and two of the three are things many Kubernetes administrators have never configured in anger. Second, the curriculum names specific projects in its own text: Cilium and Istio for pod-to-pod encryption, Kubesec and KubeLinter for static analysis, AppArmor and seccomp for kernel hardening. When a curriculum names a tool, that’s a hint about what will be on the desktop.

What you actually need to know

☺ Like you’re 10: Here’s the real substance — the things you type and the files you edit, grouped the way the exam groups them.

The gap between “I have read about this” and “I can do this in six minutes” is where the CKS lives. Below is each area, with the artifacts you should be able to produce from memory.

Cluster setup — network policy, TLS, CIS and node metadata

The highest-value muscle here is NetworkPolicy. Know that policies are additive and allow-only, that selecting a pod with any policy flips it to deny-by-default for that direction, and that {} as a pod selector means “every pod in this namespace.” The classic exam shape: apply a default deny, then re-open exactly one path.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}                 # every pod in the namespace
  policyTypes: [Ingress, Egress]  # deny both directions
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels: { app: payments-api }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: storefront }
          podSelector:
            matchLabels: { app: web }
      ports:
        - protocol: TCP
          port: 8080

Beyond that: CIS benchmarks — run kube-bench, fix a failed check by editing the static Pod manifest in /etc/kubernetes/manifests/ or the kubelet config, then confirm the component came back. Know the notorious ones: kubelet anonymous auth off, kubelet authorization mode Webhook, --profiling=false, etcd behind client certificates and encrypted at rest. Ingress with TLS is a kubernetes.io/tls Secret plus a tls: block — pair it with cert-manager in real life. Node metadata means blocking pod egress to 169.254.169.254, so a compromised pod can’t steal the node’s cloud credentials. And verify platform binaries means checking published SHA checksums before installing a kubectl or kubelet.

Cluster and system hardening — RBAC, service accounts, kernel tools

RBAC is bread and butter: Role versus ClusterRole, RoleBinding versus ClusterRoleBinding, and the reflex of kubectl auth can-i list secrets -n payments --as=system:serviceaccount:payments:api to prove the change worked. The service-account competency is more specific than people expect — disable the defaults. Set automountServiceAccountToken: false whenever a workload doesn’t talk to the API, because a mounted token is a credential sitting in the container filesystem waiting to be exfiltrated. Restricting API access means anonymous auth off, no wildcard bindings, and nothing bound to system:masters. Upgrading is kubeadm upgrade plan / apply then drain-and-upgrade nodes — the CKA drill, examined here as vulnerability management. System hardening adds the host: trim packages and services, close ports, least-privilege cloud IAM on the node role, and the two kernel tools the curriculum names by hand — seccomp and AppArmor.

Minimizing microservice vulnerabilities — Pod Security Standards and isolation

PodSecurityPolicy is gone; the replacement is Pod Security Admission — three labels on a namespace, three standards (privileged, baseline, restricted) and three modes: enforce rejects, audit annotates the audit log, warn messages the user at apply time. restricted requires a non-root user, no privilege escalation, a dropped ALL capability set and a seccomp profile.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: v1
kind: Pod
metadata:
  name: api
  namespace: payments
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault          # or Localhost + localhostProfile
  containers:
    - name: api
      image: registry.internal/payments-api@sha256:9f2c...   # digest, not tag
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        privileged: false
        capabilities:
          drop: ["ALL"]

Secrets: a Kubernetes Secret is base64, not encryption. The real controls are encryption at rest for etcd (an EncryptionConfiguration passed to the API server), tight RBAC on the secrets resource, and keeping plaintext outside the cluster with External Secrets — see Secrets & Workload Identity. Isolation covers namespace and node separation, multi-tenancy models, and sandboxed containers via a RuntimeClass pointing at gVisor or Kata. Pod-to-pod encryption is the curriculum’s own shortlist: Cilium’s transparent encryption, or Istio mTLS with a PeerAuthentication in STRICT mode.

Supply chain security — SBOMs, signing, scanning, admission

This domain is a pipeline; walk it end to end. Build a minimal base image (distroless or scratch), generate an SBOM, scan for CVEs with Trivy, statically analyse the manifest with Kubesec or KubeLinter, sign with cosign, push to a permitted registry — then have the cluster refuse anything that skipped a step.

# scan an image and fail the build on anything critical
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.internal/payments-api:1.4.3

# generate an SBOM for the artifact repository
trivy image --format cyclonedx --output sbom.json registry.internal/payments-api:1.4.3

# static analysis of the workload manifest itself
kubesec scan pod.yaml

# sign it keylessly, then verify what the cluster will be asked to run
# pin the identity — a wildcard '.*' identity accepts anyone's signature
cosign sign registry.internal/payments-api@sha256:9f2c...
cosign verify --certificate-identity-regexp '^https://github\.com/acme/.+' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.internal/payments-api@sha256:9f2c...

Enforcement lives at admission. With Kyverno you write a verifyImages rule; with OPA Gatekeeper, a constraint template in Rego. Either way the shape is the same — a permitted-registry allowlist plus a signature check:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: supply-chain-gate
spec:
  # Kyverno 1.13+ moved this onto each rule as validate.failureAction;
  # the spec-level field is still accepted and applies to every rule below.
  validationFailureAction: Enforce
  rules:
    - name: only-permitted-registries
      match:
        any:
          - resources: { kinds: [Pod] }
      validate:
        message: "Images must come from registry.internal"
        pattern:
          spec:
            # a one-element list pattern is applied to every container;
            # repeat for initContainers and ephemeralContainers to close the gap
            containers:
              - image: "registry.internal/*"
    - name: images-must-be-signed
      match:
        any:
          - resources: { kinds: [Pod] }
      verifyImages:
        - imageReferences: ["registry.internal/*"]
          attestors:
            - entries:
                - keyless:
                    issuer: https://token.actions.githubusercontent.com
                    subject: "https://github.com/acme/*"

Runtime security — behavioural detection, audit logs, immutability

Prevention fails eventually, so the last 20% is detection. Falco watches syscalls and fires on rules like “a shell was spawned in a container.” Read a Falco rule, add a simple one, and interpret an alert well enough to name the phase of attack you’re looking at. Audit logging is the other half: write an audit Policy, place it on the control-plane node, and wire it in with --audit-policy-file and --audit-log-path in the API server’s static Pod manifest. Know the four levels — None, Metadata, Request, RequestResponse — and that rules are evaluated in order, first match wins, which is exactly what lets you cap Secrets at Metadata while still logging RBAC changes in full:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Secrets and ConfigMaps carry sensitive data. Record WHO touched them,
  # never the payload — RequestResponse here would write secrets to the log.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # RBAC changes are the classic escalation path — keep the whole object
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  # log metadata for everything else in the cluster
  - level: Metadata

Immutability at runtime ties it together: readOnlyRootFilesystem: true, no package managers or shells in the image, deploy by digest rather than mutable tag, and treat any container modified in place as compromised — replace it, don’t patch it. The tools you will meet:

How to prepare using this site

☺ Like you’re 10: Every part of the test already has a page here. This table tells you which pages to read for which part.

This site was built for the CNPE, but its security and tooling shelf covers most of the CKS blueprint directly — and explains why each control exists, which a crammer won’t. Use the middle column as your reading list and the right column when a topic hasn’t clicked.

Around those, four shared pages earn their keep for any performance-based exam: Know It Cold for manifests you must type from memory, the speed reference for the context-and-namespace habits that save minutes, Practice · Security for hands-on tasks in this territory, and Triage · Networking & RBAC for when your NetworkPolicy “works” but traffic still doesn’t flow. The lab track gives you a cluster to break safely.

Exam logistics — and how to verify them

☺ Like you’re 10: It’s an online test with a person watching through your webcam, and you need the CKA badge first. Prices and timings change, so check the official page before you pay.

Some things about the CKS are structural. Others — price, duration, cut score, validity — are the sort of detail the Linux Foundation revises without announcement. This page separates them deliberately.

What we can state with confidence

What you must check on the official page

These all move, and none should be taken from a third-party page — including this one: duration, task count, pass mark, price, retake policy, eligibility window, certification validity, the simulator entitlement, and the documentation allowlist. The historical pattern for CKS has been a two-hour sitting of roughly 15–16 tasks, a cut score in the high-60s, a price around US$445 including one free retake, a two-year certification validity, and two attempts at an exam simulator bundled with registration. Those are patterns observed over past years, not commitments — and validity is the cautionary example, because the Linux Foundation has revised certification terms across the whole Kubernetes programme more than once, so a number quoted on any third-party page (this one included) may describe a rule that no longer applies.

One CKS-specific item is worth its own sentence: the documentation allowlist is wider than the CKA’s. Historically CKS candidates have been permitted the Kubernetes documentation plus the docs for a few named security projects — Trivy, Falco and AppArmor among them. Confirm the current list in the exam’s official Important Instructions, and practise navigating exactly those sites; bookmarking anything outside the allowlist is wasted effort.

↗ Official CKS page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository

Where the CKS sits in the ladder — and what to do next

☺ Like you’re 10: It’s the top of the Kubernetes stairs. Once you’re there, you either go sideways into platform building or deeper into security.

The Kubernetes line runs in a straight sequence, and the CKS is its summit:

The CKS and the CNPE are siblings, not rivals: similar seniority, barely any overlap. CKS goes down into the substrate; CNPE goes up into the developer-facing platform. Many strong platform engineers hold both, and the order is a matter of what your team needs from you this year.

What to do next

If you’ve just passed, three moves compound the value. Build the guardrails you were examined on — one control from each domain, made real: a default-deny NetworkPolicy in the namespace template, restricted Pod Security Admission for new tenants, a Kyverno signature check, Falco alerts routed somewhere a human reads. Go sideways into the platform line via the CNPA and then the CNPE, where security stops being a checklist and becomes a product feature developers experience as a golden path. Or go wider — the certifications overview maps the rest, including the associate-tier KCSA and the project credentials like Cilium and Istio that deepen the pod-to-pod encryption competency.

The CKS is the deep end of the guardrails, and guardrails are what make self-service safe enough to offer. Come at it with a live CKA, an afternoon a week on a throwaway cluster, and the security shelf of this site — and it stops being the scary one.