Certified Kubernetes Security Specialist CKS Guide

What is the CKS certification?

The CKS (Certified Kubernetes Security Specialist) is a hands-on Kubernetes security certification from the CNCF and Linux Foundation. It covers cluster setup, hardening, system hardening, minimizing microservice vulnerabilities, supply chain security, monitoring and logging, and runtime security. Passing the CKA (Certified Kubernetes Administrator) is required before attempting CKS. The exam is 2 hours and costs $395 USD.

---

The CKS (Certified Kubernetes Security Specialist) is the most advanced Kubernetes certification, focusing specifically on securing Kubernetes clusters and containerized workloads. It is a performance-based exam requiring candidates to complete security tasks in a live Kubernetes environment, not multiple-choice questions.

CKS is pursued by DevSecOps engineers, Kubernetes administrators, and platform security engineers responsible for securing container infrastructure. The certification requires passing CKA first, ensuring candidates have solid Kubernetes operational foundations before advancing to security specialization. The exam costs $395 USD.

---

Exam Overview

Detail	Information
Certification	CKS - Certified Kubernetes Security Specialist
Provider	CNCF / Linux Foundation
Exam Format	Performance-based (live Kubernetes environments)
Duration	2 hours
Passing Score	67%
Cost	$395 USD
Prerequisites	Active CKA certification required
Validity	2 years

The exam covers six domains:

1. Cluster setup (10%)
2. Cluster hardening (15%)
3. System hardening (15%)
4. Minimize microservice vulnerabilities (20%)
5. Supply chain security (20%)
6. Monitoring, logging, and runtime security (20%)

"CKS is the hardest of the three Kubernetes certifications (KCNA < CKA < CKS). CKA tests whether you can operate Kubernetes; CKS tests whether you can secure it. The security configurations are scattered across many components -- API server, etcd, kubelet, network policies, admission controllers, Pod Security Standards -- and you need to know all of them under time pressure." -- CKS certified professional community

---

Domain 1: Cluster Setup (10%)

Kubernetes API Server Security

API server security flags (critical exam topic):

# Secure authentication
--anonymous-auth=false
--authentication-mode=Node,RBAC

# Enable audit logging
--audit-log-path=/var/log/kubernetes/audit.log
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

# Disable insecure port
--insecure-port=0

# TLS configuration
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
--client-ca-file=/etc/kubernetes/pki/ca.crt

CIS Benchmark for Kubernetes

CIS Kubernetes Benchmark provides hardening recommendations. Key checks:

• API server should not allow anonymous authentication
• etcd should have TLS enabled for client connections
• Kubelet should have authentication set to webhook mode
• Network policies should be in place
• Pod Security Standards should be enforced

kube-bench is the tool for running automated CIS benchmark checks against a Kubernetes cluster. The exam may require analyzing kube-bench output and remediating findings.

---

Domain 2: Cluster Hardening (15%)

RBAC Security

Principle of least privilege in Kubernetes RBAC:

# Bad: Cluster-admin ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dangerous-binding
subjects:
  - kind: ServiceAccount
    name: default
    namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

# Better: Namespace-scoped role with minimal permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Service account security:

• Disable automatic service account token mounting when not needed: automountServiceAccountToken: false
• Use dedicated service accounts for each application, not the default service account
• Rotate service account tokens regularly

Secrets Management

Kubernetes secrets security concerns:

• Default secrets are base64-encoded (not encrypted) in etcd
• Secrets can be accessed by any pod with appropriate RBAC or by default service account
• Enable etcd encryption at rest using EncryptionConfiguration

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

---

Domain 3: System Hardening (15%)

AppArmor

AppArmor profiles restrict what a container process can do at the OS level:

apiVersion: v1
kind: Pod
metadata:
  name: secured-pod
  annotations:
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
    - name: nginx
      image: nginx

The annotation localhost/k8s-apparmor-example-deny-write applies the AppArmor profile named k8s-apparmor-example-deny-write loaded on the node to the container.

Seccomp Profiles

Seccomp (Secure Computing Mode) filters system calls:

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault  # Apply container runtime's default seccomp profile
  containers:
    - name: app
      image: myapp:1.0

RuntimeDefault applies the container runtime's default seccomp profile, which blocks dangerous system calls like ptrace and reboot.

Reducing Attack Surface

• Remove unnecessary packages: Container images should use minimal base images (scratch, distroless)
• Disable unused kernel modules: /etc/modprobe.d/ to blacklist modules
• Open ports reduction: Only expose ports required for application function

---

Domain 4: Minimize Microservice Vulnerabilities (20%)

Pod Security Standards

Pod Security Standards (replaced Pod Security Policies in Kubernetes 1.25):

Level	Description	Example Restriction
Privileged	Unrestricted	No restrictions; allows all
Baseline	Minimally restrictive	Blocks privileged containers, host namespace sharing
Restricted	Heavily restricted	Requires non-root user, drops all capabilities, disallows privilege escalation

# Enforce restricted policy on a namespace
apiVersion: v1
kind: Namespace
metadata:
  name: secure-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Security Contexts

apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
    - name: app
      image: myapp:1.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
          add:
            - NET_BIND_SERVICE  # Only if needed

OPA Gatekeeper

Open Policy Agent (OPA) Gatekeeper provides policy-based admission control:

• Constraint Templates: Define reusable policy logic in Rego language
• Constraints: Instantiate constraint templates with specific parameters
• Mutation policies: Automatically modify resources as they are admitted

---

Domain 5: Supply Chain Security (20%)

Container Image Security

Image scanning for vulnerabilities before deployment:

• Trivy: Fast, comprehensive vulnerability scanner for container images, filesystems, and IaC
• Grype: Container image vulnerability scanner from Anchore
• Snyk: Commercial scanner with developer workflow integration

# Scan an image with Trivy
trivy image nginx:1.25.0

# Scan with specific severity filter
trivy image --severity HIGH,CRITICAL nginx:1.25.0

# Scan and fail on critical findings
trivy image --exit-code 1 --severity CRITICAL myapp:1.0

Image Signing and Verification

Cosign signs container images with cryptographic signatures:

# Sign an image
cosign sign --key cosign.key myregistry/myapp:1.0

# Verify an image signature
cosign verify --key cosign.pub myregistry/myapp:1.0

Notation (CNCF project) is an alternative image signing standard integrated with OCI registries.

Image admission policy: Admission controllers (Connaisseur, Kyverno) can require signatures before admitting images to the cluster.

---

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

Falco Runtime Security

Falco is the leading cloud-native runtime security tool for Kubernetes:

• Monitors Linux system calls from all containers in real time
• Default rule set detects common attack patterns (shell spawned in container, read of sensitive files, network connection from unexpected process)
• Custom rules using YAML rule definitions
• Outputs to syslog, JSON, or webhook for SIEM integration

# Example Falco rule
- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name %container.info shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE

Audit Logging

Kubernetes audit logging records all API server requests:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log secret access at metadata level
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  # Log everything at request level
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods"]
  # Don't log kubelet health checks
  - level: None
    users: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes/status", "nodes"]

Audit levels: None (discard), Metadata (no body), Request (with request body), RequestResponse (with both bodies).

---

Frequently Asked Questions

How long should I prepare for CKS? CKS typically requires 2-3 months of preparation after passing CKA, assuming regular hands-on practice. The exam content is highly specific to Kubernetes security tooling (AppArmor, Seccomp, Falco, OPA Gatekeeper, Trivy) that requires hands-on familiarity. Candidates who attempt CKS immediately after CKA without additional security-focused practice typically need to repeat the exam.

What is the best lab environment for CKS preparation? KillerCoda (formerly Katacoda) provides free browser-based Kubernetes scenarios including CKS-specific security scenarios. Killer.sh offers two practice exam sessions with your CKS exam purchase -- these are harder than the real exam and are the best way to assess readiness. Building your own cluster on VMs using kubeadm provides the deepest understanding of cluster component configuration.

Can I use documentation during the CKS exam? Yes, the CKS exam allows access to the official Kubernetes documentation (kubernetes.io/docs), the Kubernetes blog, and official Falco documentation during the exam. Building bookmarks to frequently needed pages (API server flags, admission controller configuration, AppArmor annotation format) is recommended. Speed is critical -- you need to find information quickly when you need to reference it.

References

1. CNCF/Linux Foundation. (2025). CKS Curriculum. https://github.com/cncf/curriculum/blob/master/CKS_Curriculum_%20v1.30.pdf
2. Linux Foundation. (2025). CKS Certification. https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/
3. CIS. (2025). CIS Kubernetes Benchmark v1.9. https://www.cisecurity.org/benchmark/kubernetes
4. Falco Project. (2025). Falco Documentation. https://falco.org/docs/
5. Kim, B. (2023). Kubernetes Security and Observability. O'Reilly Media.
6. Aqua Security. (2025). Trivy Documentation. https://trivy.dev/