Courses Kubernetes security & hardeningCluster Setup

Security domains & threat model

The six domains and what an attacker does with a foothold.

Intermediate12 min · lesson 1 of 24

Securing a cluster is CKA plus a security lens — you already know how the pieces work, now the question is how they fail and who is trying to make them fail. The material here is organized the way the CKS curriculum is: six domains, each a layer an attacker has to get through, and each mapped to concrete controls you configure by hand. Nothing in this course is theoretical; every lesson ends at a manifest, a flag, or a command you would actually run.

The exam it mirrors is hands-on and unforgiving: two hours, fifteen to twenty tasks on live clusters, 67% to pass, with the official Kubernetes docs open in a second tab. That format shapes how you should learn it — not as trivia but as muscle memory. You are not asked “what is a NetworkPolicy”; you are dropped on a cluster with a task that says “default-deny the payments namespace but keep DNS working,” and the clock is running.

The six domains and their weight

before a pod runs — preventive

Cluster setup · 10%

NetworkPolicy, CIS, Ingress TLS

Cluster hardening · 15%

RBAC, API access, upgrades

System hardening · 15%

host OS, seccomp, AppArmor

while a pod runs — the high-weight 60%

Microservice security · 20%

PSS, secrets, sandboxes

Supply chain · 20%

scan, sign, verify, minimize

Runtime & detection · 20%

Falco, audit logs

Three domains before a pod runs, three about what a pod is and does at runtime. The runtime half carries 60% of the weight — and the bulk of real-world incidents.

Think like the foothold

Every control in this course answers a step an attacker takes after landing in one pod — a remote-code-execution bug in your app, a token scraped from a mounted secret, a dependency someone poisoned upstream. The useful question is never “is the cluster secure,” which has no answer, but “what can someone do from inside this one container, and how far can they get before something stops or notices them.” Every domain severs one link in that chain.

The kill chain each domain is built to break

Security context + PSS + seccomp block escalate. NetworkPolicy + metadata blocking break move. Signed, scanned images and runtime detection break persist.

Defence in depth, concretely

Defence in depth is not a slogan here — it is the assumption that any single layer will fail, so the next one has to cost the attacker something. A pod that gets popped should already be non-root with a read-only filesystem (so there is little to do), on a default-deny network (so there is nowhere to pivot), running a signed image (so it could not have been swapped), watched by Falco (so the shell fires an alert) with the API call landing in an audit log (so you can reconstruct it). No layer is trusted to be sufficient alone.

This also tells you where to spend effort. The runtime-heavy domains — microservice security, supply chain, and detection — are both the highest-weighted on the exam and the ones that matter most in a real breach, because they govern what a workload can do once it is running and whether you find out. Cluster and system hardening are the foundation under them: necessary, lower drama, and mostly a matter of knowing the flags.

Know where every config lives

Hardening happens in a small, fixed set of files: /etc/kubernetes/manifests/*.yaml for control-plane flags, /var/lib/kubelet/config.yaml for the kubelet, namespace labels for Pod Security, an EncryptionConfiguration for secrets, an audit policy for logging. Memorize the paths. On a timed exam and in a 3am incident alike, hunting for where a setting lives is how the minutes vanish.

Network policies & default-deny