CKA to CKS Bridge

This document maps every CKA topic to its CKS counterpart and identifies the entirely new security concepts you need to learn. If you passed CKA, you already have the foundation. This page shows you exactly where the walls go up.

Side-by-Side: CKA Topics vs CKS Topics

The table below compares what CKA tested against what CKS tests. Items in bold under the CKS column are entirely new material.

Domain	CKA Coverage	CKS Coverage	Delta
RBAC	Create Roles, RoleBindings, ClusterRoles	Audit RBAC misconfigs, least-privilege analysis, service account hardening, disable auto-mount tokens	Significant deepening
Network Policies	Basic ingress rules, pod selectors	Default-deny all, egress policies, namespace isolation, DNS policies	Moderate deepening
TLS / Certificates	CSR approval, kubeadm cert management	mTLS concepts, certificate rotation, PKI verification, ingress TLS	Moderate deepening
etcd	Backup and restore	Encryption at rest, etcd TLS configuration, securing etcd endpoints	New security layer
Pod Configuration	securityContext basics, resource limits	Seccomp profiles, AppArmor profiles, Linux capabilities, read-only rootFS, no privilege escalation	Major new material
Secrets	Create and mount secrets	Encrypt secrets at rest, avoid env var secrets, external secret stores	New security layer
Admission Control	Know admission controllers exist	OPA/Gatekeeper policies, Pod Security Admission, ImagePolicyWebhook, validating/mutating webhooks	Entirely new
Image Management	Pull images from registries	Image scanning (Trivy), allowed registry enforcement, image digest pinning, static analysis	Entirely new
Runtime Security	Not covered	Falco rules and alerts, syscall monitoring, audit logging, behavioral detection	Entirely new
OS Hardening	Basic Linux commands	Reduce attack surface, disable services, kernel hardening, restrict node access	Entirely new
CIS Benchmarks	Not covered	kube-bench, remediate CIS findings, benchmark interpretation	Entirely new

Critical Gap

If you skipped through RBAC, Network Policies, or TLS during CKA prep (common with "just enough to pass" study), you must go back and solidify those foundations before tackling CKS. CKS assumes deep fluency with these topics.

Security Concepts CKA Does NOT Cover

Mutual TLS (mTLS)

In standard TLS, only the server presents a certificate. The client verifies the server's identity, but the server does not verify the client's identity. In mTLS, both parties present certificates and verify each other.

Why it matters for CKS: Service mesh solutions (Istio, Linkerd) use mTLS to encrypt all pod-to-pod traffic. CKS expects you to understand the concept and know that services should not communicate over plaintext within the cluster.

Admission Controllers (In Depth)

CKA barely mentions admission controllers. CKS requires you to understand the full pipeline:

Key admission controllers for CKS:

Controller	Type	Purpose
PodSecurity	Validating	Enforces Pod Security Standards (Privileged/Baseline/Restricted) at namespace level
OPA Gatekeeper	Both	Custom policies written in Rego (e.g., "all images must come from registry.internal.io")
ImagePolicyWebhook	Validating	Calls an external webhook to approve/deny container images
NodeRestriction	Validating	Limits what kubelets can modify (only their own Node and Pod objects)
AlwaysPullImages	Mutating	Forces imagePullPolicy: Always to prevent using cached unauthorized images

Image Scanning & Supply Chain

CKA does not cover container image security at all. CKS expects you to:

1. Scan images using Trivy to identify CVEs by severity (CRITICAL, HIGH, MEDIUM, LOW)
2. Enforce allowed registries -- only permit images from trusted sources
3. Pin images by digest rather than tag (nginx@sha256:abc123... instead of nginx:latest)
4. Perform static analysis on Kubernetes manifests to find security issues before deployment

Runtime Security

CKA has zero runtime security content. CKS introduces:

1. Falco -- monitors Linux syscalls in real-time using eBPF/kernel module and alerts on suspicious activity (e.g., shell spawned in container, sensitive file read)
2. Audit logging -- configuring the API server to log all requests with different levels (None, Metadata, Request, RequestResponse)
3. Immutable containers -- enforcing readOnlyRootFilesystem: true and detecting containers that write to disk at runtime
4. Behavioral analysis -- identifying anomalous processes, network connections, or file access within containers

Syscall Filtering (Seccomp)

Seccomp (Secure Computing Mode) restricts which system calls a container can make to the Linux kernel. This is a critical defense-in-depth mechanism:

Kubernetes Security Layers

Understanding how security layers stack in Kubernetes is essential for CKS. Every request and every workload passes through multiple security boundaries:

Defense in Depth

CKS tests your ability to implement security at every layer. A question might require you to fix a Network Policy (Layer 1), harden a securityContext (Layer 4), and configure Falco (Layer 5) -- all in the same scenario.

Key Linux Security Concepts

Namespaces (Kernel, not Kubernetes)

Linux kernel namespaces are the fundamental isolation mechanism for containers. Each namespace type isolates a different resource:

Namespace	What It Isolates	Security Implication
PID	Process IDs	Container cannot see host processes (unless hostPID: true)
NET	Network stack	Container gets its own IP, ports, routing table
MNT	Mount points	Container has its own filesystem view
UTS	Hostname	Container can have its own hostname
IPC	Inter-process communication	Shared memory segments are isolated
USER	User and group IDs	UID 0 in container can map to non-root on host
CGROUP	cgroup root directory	Container cannot see host cgroup hierarchy

Exam Alert

If a pod has hostPID: true, hostNetwork: true, or hostIPC: true, it breaks namespace isolation. CKS frequently tests your ability to identify and remediate these dangerous settings.

cgroups (Control Groups)

cgroups limit, account for, and isolate resource usage (CPU, memory, I/O, etc.) of a collection of processes. In Kubernetes:

• Resource requests map to cgroup minimum guarantees
• Resource limits map to cgroup hard caps
• If a container exceeds its memory limit, the kernel OOM-kills it
• If a container exceeds its CPU limit, it gets throttled

Linux Capabilities

Traditional Unix has two categories: root (UID 0) with all privileges, and everyone else. Linux capabilities break root's privileges into ~40 distinct capabilities:

Capability	What It Allows	CKS Action
CAP_NET_ADMIN	Modify network configuration	Drop unless needed
CAP_SYS_ADMIN	Broad sysadmin operations (mount, etc.)	Always drop -- almost equivalent to root
CAP_SYS_PTRACE	Trace/debug other processes	Drop unless debugging
CAP_NET_RAW	Use raw sockets (ping, packet crafting)	Drop unless needed
CAP_CHOWN	Change file ownership	Drop in most cases
CAP_SETUID	Set UID of a process	Drop to prevent privilege escalation
CAP_DAC_OVERRIDE	Bypass file permission checks	Drop in most cases

CKS best practice: Drop ALL capabilities, then add back only what the application needs:

securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE  # Only if binding to ports < 1024

Seccomp Profiles

Seccomp uses Berkeley Packet Filter (BPF) programs to filter system calls. The default container runtime profile blocks ~60 dangerous syscalls while allowing ~300 safe ones.

Syscall	Why It's Blocked	Attack Vector
mount	Mount filesystems	Escape container by mounting host FS
ptrace	Trace processes	Debug/inspect other containers
reboot	Reboot the system	Denial of service
clock_settime	Change system clock	Tamper with logs and certificates
unshare	Create new namespaces	Privilege escalation

AppArmor

AppArmor is a Linux Security Module (LSM) that confines programs by defining what files, network resources, and capabilities they can access. It operates in two modes:

• Enforce -- violations are blocked and logged
• Complain -- violations are only logged (useful for building profiles)

# Example AppArmor profile for a web server container
#include <tunables/global>

profile k8s-web-server flags=(attach_disconnected) {
  #include <abstractions/base>

  # Allow reading web content
  /var/www/html/** r,

  # Allow network access
  network tcp,

  # Deny everything else by default
  deny /etc/shadow r,
  deny /proc/*/mem r,
  deny /sys/** w,
}

Cryptography Basics Needed for CKS

TLS / PKI

You used TLS in CKA for certificate signing requests. CKS expects deeper understanding:

Key concepts for CKS:

Concept	What to Know
Certificate chain	CA -> intermediate (optional) -> leaf cert. Verify with openssl verify
SANs	Subject Alternative Names allow one cert for multiple DNS names / IPs
Certificate rotation	kubeadm certs renew and automatic kubelet cert rotation
Certificate expiry	kubeadm certs check-expiration or openssl x509 -enddate -noout -in <cert>
Private key security	Keys must have 0600 permissions, owned by root

RBAC Token Types

CKS requires understanding the different authentication token types:

Token Type	Description	CKS Relevance
Service Account Token	JWT signed by sa.key, mounted into pods	Disable auto-mount with automountServiceAccountToken: false
Bootstrap Token	Short-lived tokens for node joining	Ensure they expire and are cleaned up
OIDC Token	Tokens from external identity providers	Understand API server OIDC flags
Static Token (deprecated)	Tokens stored in a file on the API server	Must be disabled -- CKS tests this
X.509 Client Cert	Certificates embedded in kubeconfig	Understand CN = username, O = group

Security Anti-Pattern

Static token files (--token-auth-file) and basic auth files (--basic-auth-file) should never be used. CKS may test whether you can identify and remove these insecure authentication methods from the API server configuration.

What to Study First

Based on the gaps identified above, here is the recommended priority for CKA holders:

TIP

Spend the most time on Priority 1 and Priority 2. These topics are entirely new from CKA and carry the most weight on the exam. If you are comfortable with Linux security primitives, you can move through Priority 1 quickly and focus on the tooling.