CKS Certification

The Certified Kubernetes Security Specialist (CKS) is the CNCF’s security-focused follow-up to the CKA: a performance-based, hands-on exam covering cluster hardening, supply-chain security, and runtime threat detection. A valid CKA is a hard prerequisite — CKS assumes you can already administer a cluster and tests whether you can defend one. Source: Falco for Kubernetes Security — CKS Scenarios

Position on the Certification Path

StageCertificationFocus
FoundationCKACluster administration — scheduling, networking, storage, troubleshooting
SpecializationCKSCluster hardening, minimizing attack surface, supply chain, runtime security

Many CKA topics are direct CKS prerequisites: RBAC, NetworkPolicies, TLS/certificates, and etcd backup all reappear as security controls. The CKS then layers specialized tooling on top — Falco for runtime detection, admission policy engines for governance, image scanning for the supply chain.

Exam Domain Highlights

DomainRepresentative Skills
Cluster SetupNetworkPolicies, CIS benchmarking, ingress TLS, verifying platform binaries
Cluster HardeningRBAC least privilege, ServiceAccount restrictions, API-server auditing
System HardeningAppArmor/seccomp profiles, minimizing host OS attack surface
Supply Chain SecurityImage scanning (Trivy), image allow-lists, static analysis of manifests
Monitoring, Logging & Runtime SecurityFalco rules, audit logging, detecting malicious activity at runtime

Falco Scenario Patterns

The runtime-security domain is where Falco scenarios appear, and they follow a small set of repeatable patterns — effectively guaranteed marks once the mechanics are muscle memory. Source: Falco for Kubernetes Security — CKS Scenarios

Pattern 1: Write a New Rule, Find the Offending Pod

“One of these Pods is accessing /dev/mem — find it and delete its workload.”

  1. Write a custom rule keyed on fields from the Falco supported fields doc: condition fd.name = /dev/mem and evt.type in (open, openat); output interpolating %proc.cmdline, %user.name, %container.id, %container.image.repository, %k8s.pod.name.
  2. Load it into the cluster deployment: create a ConfigMap from the rules file, kubectl edit the Falco DaemonSet to add volume + volumeMounts, then rolling-restart.
  3. Grep the Falco pod logs for the alert, read k8s.pod.name, and kubectl delete deploy <name>.

Pattern 2: Custom Rule on a Host Install

  1. Edit /etc/falco/falco_rules.local.yaml — the designated file for local rules (never the shipped falco_rules.yaml unless the task says so).
  2. Run falco -M <seconds> to capture a bounded window of events.
  3. Map the alerted container ID back to a Pod with crictl ps | grep <id> — host installs lack Kubernetes metadata enrichment.

Pattern 3: Modify a Built-in Rule’s Output

  1. Find the target rule (e.g., Terminal shell in container) in /etc/falco/falco_rules.yaml.
  2. Replace its output string with the required format, using %field interpolations from the supported-fields reference.
  3. Restart Falco and trigger the condition (e.g., docker run -it ubuntu bash) to verify the new format.

Exam Survival Notes

  • The supported-fields documentation is the key reference — knowing how to search it matters more than memorizing fields.
  • Falco is usually pre-installed in exam environments; installation itself is rarely the task.
  • Know where each config lives: falco.yaml (engine config, e.g. syslog_output), falco_rules.yaml (defaults), falco_rules.local.yaml (customs).

See Also


Tags: cks kubernetes security certification cncf falco devsecops