Introduction
Most KCSA candidates over-study controls — Pod Security Standards, NetworkPolicies, RBAC — and under-study threats. That’s a mistake, because the Kubernetes Threat Model is a full domain on the Kubernetes and Cloud Native Security Associate (KCSA) exam, and it’s the one that turns an otherwise control-by-control study plan into something coherent. Once you can describe what an attacker is trying to do and where the trust boundaries are, every control you’ve learned suddenly has a reason to exist.
The threat-model questions on the KCSA are conceptual, not hands-on. You won’t be asked to write a NetworkPolicy. You’ll be asked things like: “An attacker who has compromised a single application Pod wants to read Secrets belonging to other workloads. Which trust boundary must they cross, and which control most directly prevents it?” That’s a threat-modeling question, and you answer it by reasoning about data flow and boundaries — not by memorizing YAML.
This guide walks through the threat model the way the exam frames it: trust boundaries first, then the canonical attacker goals (persistence, privilege escalation, network attacks, data access, supply-chain compromise), and finally how the STRIDE methodology maps onto Kubernetes. By the end you’ll have a mental map you can apply to any scenario question. If you want the broader control landscape alongside this, pair it with the 4Cs of Cloud Native Security guide.
What a Threat Model Actually Is
A threat model is a structured way of answering four questions about a system:
- What are we building? (the architecture and its components)
- What can go wrong? (the threats)
- What are we going to do about it? (the controls)
- Did we do a good enough job? (validation)
For Kubernetes, “what are we building” is a distributed system with a control plane, worker nodes, a network fabric, and a software supply chain feeding container images into it. “What can go wrong” is the set of attacker goals the KCSA enumerates. The exam lives mostly in questions 1 and 2 — it wants you to recognize the components, the boundaries between them, and the realistic ways an attacker moves through them.
The single most useful concept here is the trust boundary: a line in the architecture where the level of trust changes, and therefore where data and requests must be authenticated, authorized, and validated. Attacks happen at boundaries. Get the boundaries right and the rest of the threat model follows.
Kubernetes Trust Boundaries and Data Flow
Picture a request flowing into a cluster and a workload running inside it. It crosses several trust boundaries:
| Boundary | Between | What enforces it |
|---|---|---|
| External → API server | Internet/user and the control plane | Authentication (certs, tokens, OIDC) + RBAC authorization + admission control |
| API server → etcd | Control plane API and cluster datastore | mTLS, etcd encryption at rest, network isolation |
| Control plane → node (kubelet) | API server and worker nodes | Kubelet authentication/authorization, TLS |
| Node → Pod | Host kernel and container | Namespaces, cgroups, seccomp, AppArmor/SELinux, Pod Security Standards |
| Pod → Pod | One workload and another | NetworkPolicy, service account scoping, mTLS (service mesh) |
| Pod → cloud provider | Workload and cloud APIs | IAM roles for service accounts / instance metadata controls |
Every KCSA threat-model question is, at heart, asking which of these boundaries an attacker is trying to cross and what guards it. When you read a scenario, your first move should be to locate the boundary. “Compromised container wants to escape to the host” → the node → Pod boundary, guarded by seccomp/AppArmor and the Pod Security Standards. “Compromised Pod wants to talk to a database Pod it shouldn’t” → the Pod → Pod boundary, guarded by NetworkPolicy.
A key insight the exam tests: etcd is the crown jewels. Every Secret, every ConfigMap, the entire desired state of the cluster lives there in plaintext unless you’ve enabled encryption at rest. Anyone with direct etcd access bypasses RBAC entirely, because RBAC is enforced at the API server, not at the datastore. That’s why “an attacker gained read access to etcd” is always a worst-case scenario in a question.
The Canonical Attacker Goals
The KCSA threat model organizes threats around what an attacker is trying to achieve. These map closely to the official exam subdomains and to real-world frameworks like the MITRE-style Kubernetes threat matrix. Learn these six goals and you can classify almost any scenario.
1. Persistence
Once an attacker gets in, they want to stay in — surviving Pod restarts, node reboots, and even cluster upgrades. Persistence techniques in Kubernetes include:
- Deploying a malicious DaemonSet so a backdoor Pod runs on every node, including new ones.
- Creating a CronJob that periodically re-establishes a reverse shell.
- Adding a rogue static Pod manifest to a node’s
/etc/kubernetes/manifestsdirectory — the kubelet will keep restarting it, and it won’t appear in normal RBAC-controlled workflows the same way. - Creating extra ServiceAccounts and tokens, or a ClusterRoleBinding that grants a dormant identity cluster-admin for later use.
- Tampering with admission webhooks to inject containers into future workloads.
The exam wants you to recognize why these are dangerous: they abuse legitimate Kubernetes mechanisms, so they blend in with normal operations. The defense is least-privilege RBAC, audit logging to detect the creation events, and image/admission controls.
2. Privilege Escalation
This is the most heavily tested attacker goal. The attacker starts with limited access (often a single compromised container) and tries to gain more. Common paths:
- Privileged containers and host namespaces. A Pod running with
privileged: true,hostPID,hostNetwork, orhostPathmounts can often reach the host filesystem or processes and escape the container boundary entirely. - Dangerous Linux capabilities.
CAP_SYS_ADMIN,CAP_NET_RAW, orCAP_SYS_PTRACEgranted to a container widen the blast radius dramatically. - Stolen ServiceAccount tokens. Every Pod can, by default, mount a ServiceAccount token at
/var/run/secrets/kubernetes.io/serviceaccount/token. If that account has broad RBAC permissions, a compromised app inherits them. This is whyautomountServiceAccountToken: falsematters. - Node-to-cluster escalation. A compromised kubelet credential or node can be leveraged to read Secrets of Pods scheduled on that node.
Here’s a YAML example of exactly the kind of Pod spec the exam flags as a privilege-escalation risk:
apiVersion: v1
kind: Pod
metadata:
name: dangerous
spec:
hostPID: true # sees all host processes
containers:
- name: app
image: busybox
securityContext:
privileged: true # full host access — escape risk
capabilities:
add: ["SYS_ADMIN"]
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: / # mounts the entire node filesystemThe control that most directly blocks this is the Pod Security Standards at the restricted (or at least baseline) level, enforced by the Pod Security Admission controller. Recognizing that mapping — privilege escalation via Pod spec → Pod Security Standards — is worth several marks.
3. Network Denial of Service and Lateral Movement
The cluster network is flat by default: every Pod can reach every other Pod. That makes two attacker goals easy unless you intervene:
- Lateral movement. From one compromised Pod, reach databases, internal APIs, and the cloud metadata endpoint (
169.254.169.254) to steal credentials. - Denial of service. Exhaust node resources (CPU, memory, PIDs, ephemeral storage) so legitimate workloads are evicted, or flood the network.
The defenses the exam pairs with these are NetworkPolicies (default-deny, then explicitly allow), ResourceQuotas and LimitRanges (cap resource consumption), and blocking access to the instance metadata service. A question describing “a compromised Pod reached the AWS metadata endpoint and stole the node’s IAM credentials” is testing whether you know to restrict egress to 169.254.169.254.
4. Malicious Code and Compromised Applications in Containers
This is the supply-chain angle: the threat that the container image itself is malicious or vulnerable before it ever runs.
- A base image with a known CVE.
- A typosquatted or backdoored dependency pulled in at build time.
- An image from an untrusted registry.
- A legitimate app with an exploitable vulnerability (e.g., RCE) that becomes the initial foothold.
Defenses: image vulnerability scanning, image signing and verification (Sigstore/cosign), admission control that only allows images from trusted registries, and running containers as non-root with a read-only root filesystem. The exam connects this goal to the code and container layers of the 4Cs model.
5. Access to Sensitive Data
The attacker’s end goal is usually data: Secrets, customer records, tokens, certificates. Threats here include reading Kubernetes Secrets (especially via etcd, as noted), intercepting unencrypted traffic, and accessing mounted volumes.
Defenses: encryption at rest for etcd, RBAC scoping on Secrets, external secret managers (Vault, cloud KMS), and TLS everywhere. Remember the exam fact: Kubernetes Secrets are only base64-encoded, not encrypted, by default — base64 is encoding, not security.
6. Attacker on the Network
This goal assumes the attacker can observe or manipulate network traffic — sniffing, man-in-the-middle, or spoofing. In a cloud-native context this includes intercepting pod-to-pod traffic, control-plane traffic, or traffic to external services. The defenses are mutual TLS (often via a service mesh), TLS for the API server and etcd, and network segmentation.
Mapping Kubernetes Threats to STRIDE
The KCSA expects familiarity with STRIDE, Microsoft’s threat-classification methodology. STRIDE gives you six categories; mapping them to Kubernetes makes abstract scenarios concrete:
| STRIDE category | Meaning | Kubernetes example | Primary control |
|---|---|---|---|
| Spoofing | Pretending to be someone else | Forged or stolen ServiceAccount token | Strong authentication, short-lived tokens |
| Tampering | Unauthorized modification | Mutating admission webhook injecting a sidecar; image tampering | Admission control, image signing |
| Repudiation | Denying an action with no proof | No audit logging of delete actions | API server audit logs |
| Information disclosure | Leaking data | Reading Secrets from etcd or env vars | Encryption at rest, RBAC, external secrets |
| Denial of service | Making the system unavailable | Resource exhaustion evicting Pods | ResourceQuota, LimitRange, priority classes |
| Elevation of privilege | Gaining higher rights | Privileged Pod escaping to the host | Pod Security Standards, least-privilege RBAC |
When a scenario question describes an attack, silently classify it under STRIDE first — it instantly narrows the control you should pick. “An admin can’t prove who deleted a Deployment” is Repudiation, so the answer involves audit logging, not RBAC.
A Worked Threat-Modeling Scenario
Let’s apply the whole model to a question like one you’ll see:
A web application Pod is compromised through an unpatched dependency. The attacker reads the Pod’s mounted ServiceAccount token, uses it to list Secrets across all namespaces, and then deploys a DaemonSet that runs a crypto-miner on every node. Identify, in order, the boundaries crossed and the control that would have most directly stopped each step.
Reason through it:
- Initial foothold — malicious code / compromised application in a container. The unpatched dependency is a code/supply-chain failure. Control: vulnerability scanning + patching.
- Token theft → cross-namespace Secret access — this is privilege escalation plus information disclosure. The boundary crossed is Pod → API server, abused via an over-permissioned ServiceAccount. Controls:
automountServiceAccountToken: false, least-privilege RBAC scoped to a single namespace. - DaemonSet deployment — this is persistence. The attacker abused their (excessive) RBAC to create a cluster-wide workload. Control: least-privilege RBAC again, plus audit logging and admission control to block untrusted images.
Notice how the same root cause — an over-permissioned ServiceAccount — enabled two of the three steps. That recurring theme (least privilege as the highest-leverage control) is exactly what the threat-model domain is trying to teach you, and it ties directly into the exam topics breakdown you should be drilling.
How the KCSA Tests the Threat Model
A few patterns to expect on exam day:
- Boundary identification. “Which trust boundary does X cross?” — locate it on the table above.
- Attacker-goal classification. “This is an example of which threat?” — match it to persistence, privilege escalation, etc.
- Best control selection. Given a threat, pick the most direct mitigation. The exam often lists several controls that would help — you must pick the one that addresses the specific boundary in question.
- STRIDE classification. Map a described attack to its STRIDE category.
- Worst-case reasoning. “Which of these gives an attacker the most access?” — usually etcd access or a privileged/host-namespace Pod.
The trap is choosing a control that’s good practice but doesn’t address this threat. If the question is about lateral movement between Pods, encryption at rest is a fine practice but the direct answer is a NetworkPolicy. Read for the boundary.
Building the Reflex With Practice
The threat-model domain rewards a particular reflex: read a scenario, locate the boundary, classify the attacker’s goal, then pick the most direct control. You can’t build that reflex by reading alone — you build it by working through dozens of scenario questions until the mapping becomes automatic.
That’s exactly the gap structured practice fills. The KCSA Mock Exam Bundle is built around scenario-driven questions with detailed explanations that walk through the boundary-and-control reasoning behind each answer — so by exam day you’ve already threat-modeled the same patterns the real exam throws at you. Pair it with a structured timeline using the KCSA study plan, and if you’re weighing this cert against the hands-on CKS, read KCSA vs CKS to see how the conceptual threat model here becomes practical defense work there.
Frequently Asked Questions
How much of the KCSA exam is the threat model?
The Kubernetes Threat Model is one of the six official domains and accounts for roughly 16% of the exam. But its real weight is higher than that number suggests, because threat-modeling reasoning underpins questions across the other domains too — knowing why a control exists helps you pick it correctly anywhere.
Do I need to memorize STRIDE for the KCSA?
You should understand STRIDE conceptually and be able to map a described Kubernetes attack to the right STRIDE category. You won’t be asked to recite the acronym, but classification questions are fair game, and STRIDE is the fastest way to narrow down the correct control.
What’s the single most important trust boundary to understand?
The Pod → API server boundary via the ServiceAccount token, closely followed by the API server → etcd boundary. Most privilege-escalation and data-disclosure scenarios route through an over-permissioned ServiceAccount or direct etcd access, so those two boundaries appear again and again.
Why are Kubernetes Secrets considered a weak point?
By default, Secrets are stored base64-encoded in etcd — that’s encoding, not encryption. Without encryption at rest enabled and tight RBAC, anyone with etcd access or broad Secret read permissions can extract them in plaintext. The exam expects you to know this distinction cold.
Is the threat-model domain hands-on?
No. KCSA is a multiple-choice exam, so the threat-model questions are conceptual — identifying boundaries, classifying attacker goals, and selecting controls. The hands-on application of these defenses is tested on the CKS exam instead.
Conclusion
The Kubernetes threat model is the connective tissue of the KCSA: trust boundaries tell you where attacks happen, the six attacker goals tell you what attackers want, and STRIDE gives you a vocabulary to classify any scenario quickly. Internalize the boundary table and the attacker-goal list, and the control-selection questions stop being memorization and start being deduction.
Read this alongside the 4Cs of Cloud Native Security for the control landscape, drill the KCSA exam topics for full coverage, and follow the KCSA study plan to time your prep. Then prove the reflex is automatic by working through realistic scenarios in the KCSA Mock Exam Bundle — because on the threat-model domain, the candidate who has already reasoned through a hundred attack paths is the one who answers in seconds.