Skip to main content

CKS: Certified Kubernetes Security Specialist

If you have passed the CKA, you know how to build a cluster. But can you secure it against a state-sponsored cyberattack? The CKS exam tests your ability to harden Linux nodes, scan container images for vulnerabilities, lock down network policies, and detect runtime intrusions using advanced security tools.

1. Exam Overview and Mechanics
#

  • Prerequisite: You MUST hold an active CKA (Certified Kubernetes Administrator) certification to sit for the CKS.
  • Duration: 2 Hours
  • Format: 100% Performance-Based (Terminal). 15-20 practical tasks.
  • Passing Score: 67%
  • Environment: Proctored online. Browser-based terminal.
  • Allowed Resources: One browser tab open to kubernetes.io/docs, PLUS access to the documentation for specific CNCF tools (Trivy, Falco, AppArmor, Cilium).

The CKS is notoriously brutal because it covers technologies outside of core Kubernetes. You must master third-party open-source security tools.


2. Curriculum Breakdown
#

The CKS curriculum is divided into 6 distinct security domains, following the lifecycle of a cloud-native application.

Domain 1: Cluster Setup (10%)
#

  • Network Policies: Restrict traffic between namespaces default-deny rules.
  • CIS Benchmarks: Use the kube-bench tool to scan the cluster nodes and API server for CIS (Center for Internet Security) compliance violations, and fix the flags in the kube-apiserver.yaml static pod manifest.
  • Ingress Security: Secure Ingress resources using TLS certificates.

Domain 2: Cluster Hardening (15%)
#

  • RBAC: Implement Least Privilege. Remove excessive permissions from default ServiceAccounts.
  • API Access: Restrict access to the Kubernetes API using Network Boundaries or specific authentication methods.
  • Version Upgrades: Frequently, security vulnerabilities are patched in newer Kubernetes versions. You may need to perform a kubeadm upgrade (similar to the CKA).

Domain 3: System Microservice Vulnerabilities (20%)
#

  • OS Hardening: Manage Kubernetes Secrets securely. Understand how to encrypt secrets at rest in etcd.
  • Container Isolation: You must understand how to isolate workloads using specialized Container Runtimes (e.g., gVisor or Kata Containers) via RuntimeClasses.

Domain 4: Supply Chain Security (20%)
#

  • Image Footprint: Minimize base image footprint (e.g., switching from Ubuntu to Alpine or Distroless).
  • Image Scanning: Use Trivy to scan Docker images for CVEs (Common Vulnerabilities and Exposures) and reject images with CRITICAL vulnerabilities.
  • Image Signature: Verify image signatures using tools like cosign to ensure the image was not tampered with during transit.

Domain 5: Microservice Vulnerabilities (20%)
#

  • Pod Security Admission: Replace the deprecated PodSecurityPolicies (PSP) with the modern Pod Security Admission (PSA) controller to enforce restricted policies on namespaces.
  • OPA Gatekeeper: Understand how to write or apply Rego policies to block insecure deployments (e.g., blocking any container that tries to run as root).
  • Mutual TLS (mTLS): Understand how Service Meshes provide identity and encryption between microservices.

Domain 6: Monitoring, Logging, and Runtime Security (15%)
#

  • Runtime Threat Detection: Use Falco to detect malicious activity at runtime (e.g., a process trying to write to /etc/shadow inside a container, or someone launching a shell bash inside a web server pod).
  • Immutability: Ensure containers are running with read-only root filesystems (readOnlyRootFilesystem: true).
  • Syscall Restriction: Apply seccomp profiles and AppArmor profiles to pods to restrict which Linux Kernel system calls the container can execute.

3. Terminal Survival Strategies for the CKS
#

Strategy 1: The Third-Party Tool Documentation
#

Unlike the CKA, you are allowed to browse the documentation for Trivy, Falco, and AppArmor. However, their documentation sites are massive.

  • Trivy: Memorize the command trivy image --severity CRITICAL <image_name>. You will be asked to scan images and delete the vulnerable ones.
  • Falco: You will likely be asked to edit a Falco rule. Know where the rules are stored (/etc/falco/falco_rules.local.yaml) and how to restart the Falco service (systemctl restart falco).

Strategy 2: Breaking the API Server
#

In the CKS, you will spend a lot of time editing the /etc/kubernetes/manifests/kube-apiserver.yaml file (to enable Audit Logging or Encryption at Rest).

  • WARNING: If you make a typo in this YAML file, the API Server will instantly crash, and kubectl will stop working entirely.
  • SURVIVAL TACTIC: Always make a backup of the manifest before editing it.
    cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak
    If you break the API server, simply copy the backup file back into the manifests folder, and the kubelet will automatically restart the API server.

Strategy 3: Auditing and Logging
#

You must know how to configure Kubernetes Audit Logging. Memorize the structure of an AuditPolicy file. You will be asked to log all metadata for requests hitting the secrets API, but ignore requests hitting the pods API.

Strategy 4: Seccomp and AppArmor
#

You will be asked to apply security profiles to Pods.

  • Seccomp: Typically applied directly in the Pod YAML via the securityContext:
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: profiles/audit.json
  • AppArmor: Typically applied via annotations on the Pod metadata:
    annotations:
      container.apparmor.security.beta.kubernetes.io/my-container: localhost/my-profile

Conclusion
#

The CKS is the summit of the Kubernetes mountain. Achieving this certification requires immense dedication, deep Linux kernel knowledge, and a paranoid security mindset.

If you pass the CKS, you are in the top 1% of Kubernetes engineers globally. Good luck on your journey!