Getting Started with CKS: A Complete Study Guide

The Certified Kubernetes Security Specialist (CKS) is the hardest of the three Kubernetes certifications from the Linux Foundation. It's a hands-on, performance-based exam that tests your ability to secure a Kubernetes cluster end-to-end: hardening the control plane, locking down workloads, securing the supply chain, and detecting threats at runtime.

You need a valid CKA before you can register for the CKS. If you've already passed the CKA, you know what the exam format feels like. The CKS raises the stakes significantly.

Exam Domains

The CKS curriculum covers six domains:

Supply chain security and runtime security together make up 40% of the exam. Don't under-prepare for these.

Core Concepts to Master

RBAC and Least Privilege

RBAC is foundational. You need to be comfortable creating Roles, ClusterRoles, and their bindings, and you need to know when to use each. The key principle is least privilege: every service account, user, and process should have only the permissions it needs.

# Audit what a service account can do
kubectl auth can-i --list --as=system:serviceaccount:default:my-sa

# Create a role with minimal permissions
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods \
  -n my-namespace

Watch for common over-permissioning mistakes: binding cluster-admin to a CI/CD service account, shared service accounts across namespaces, or service accounts with automountServiceAccountToken: true when API access isn't needed.

Pod Security and Security Contexts

The CKS exam expects you to know Pod Security Standards and how to enforce them via namespace labels:

apiVersion: v1
kind: Namespace
metadata:
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

You should also be comfortable writing security contexts that enforce non-root execution, read-only filesystems, and dropped capabilities:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

Seccomp and AppArmor

Seccomp profiles restrict which system calls a container process can make. AppArmor profiles restrict file, capability, and resource access at the kernel level. Both reduce the attack surface if a container is compromised.

Apply a seccomp profile in the pod spec:

securityContext:
  seccompProfile:
    type: RuntimeDefault

AppArmor profiles are applied via annotations (or the appArmorProfile field in newer Kubernetes versions):

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/my-container: runtime/default

Network Policies

By default, all pods can reach all other pods. NetworkPolicies let you restrict this. For the CKS, you need to be able to write policies that:

• Deny all ingress and egress by default
• Allow specific pod-to-pod traffic by label selector
• Restrict egress to specific ports or external CIDRs

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: secure-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Supply Chain Security

This domain covers image signing, vulnerability scanning, registry allowlisting, and static analysis of manifests. Tools you should know:

• Trivy for scanning container images for CVEs
• Cosign/Sigstore for signing and verifying images
• KubeLinter / Kubesec for static analysis of YAML manifests
• OPA/Gatekeeper or Kyverno for enforcing admission policies at runtime

# Scan an image for vulnerabilities
trivy image nginx:latest

# Generate an SBOM
trivy image --format cyclonedx nginx:latest

Runtime Security with Falco

Falco monitors kernel system calls using eBPF and alerts on anomalous behaviour: unexpected shell spawns, sensitive file reads, privilege escalations, and unexpected network connections.

Know the structure of a Falco rule and how to read its output. The exam won't ask you to write complex rules from scratch, but understanding what Falco detects and how to interpret alerts is required.

Audit Logging

The Kubernetes API server can write audit logs for every request. You configure this via --audit-policy-file and --audit-log-path on the API server. Know the four audit stages (RequestReceived, ResponseStarted, ResponseComplete, Panic) and the four verbosity levels (None, Metadata, Request, RequestResponse).

Study Tips

The CKS is hands-on. Reading about these tools isn't enough. You need to have actually configured them on a real cluster.

Build a lab environment with kind or kubeadm and practice:

• Enabling audit logging on a kubeadm cluster
• Applying and verifying seccomp profiles
• Writing and testing NetworkPolicies
• Scanning images with Trivy and interpreting results
• Writing Falco rules and testing them

Time is tight. The CKS gives you 2 hours for 15-20 tasks. Practice until common operations (writing security contexts, creating RBAC resources, applying NetworkPolicies) are fast and automatic.

Use our CKS practice questions to test your conceptual knowledge, then take what you've learned to a real cluster.

Recommended Resources

• Official CKS Curriculum (CNCF GitHub)
• Kubernetes Security Documentation
• CKS practice questions on this site
• killer.sh CKS Simulator — two sessions included with exam registration
• Kubernetes Security Essentials (LFS260)

Final Thoughts

The CKS rewards people who understand security at a systems level, not just people who can memorise kubectl commands. If you're serious about Kubernetes security, this certification is worth pursuing. Give yourself 8-12 weeks of focused preparation if you're starting from the CKA, and spend most of that time on a real cluster.