KCSA — Threat Modeling Fundamentals

7 minute read

What Is Threat Modeling?

Threat modeling is a systematic approach to identifying, quantifying, and prioritizing potential threats to a system. Rather than waiting for an attack to happen, threat modeling proactively asks:

  • What are we building? (system architecture)
  • What can go wrong? (threats)
  • What are we going to do about it? (mitigations)
  • Did we do a good enough job? (validation)

In Kubernetes, threat modeling means examining every component — from the API server to individual containers — and understanding how an attacker could exploit them.

Threat modeling is not a one-time activity. It should be revisited whenever the architecture changes, new components are added, or new vulnerabilities are discovered.

The STRIDE Model

STRIDE is the most important threat modeling framework for the KCSA exam. Developed by Microsoft, it categorizes threats into six types. Each letter represents a different class of threat.

Category Threat Description Kubernetes Example
S — Spoofing Impersonating an identity Pretending to be a legitimate user or service Stolen ServiceAccount token used to authenticate to the API server
T — Tampering Modifying data Unauthorized changes to data in transit or at rest Modifying a ConfigMap or Secret to inject malicious configuration
R — Repudiation Denying actions Claiming an action was not performed Disabling or deleting audit logs to hide unauthorized API calls
I — Information Disclosure Exposing data Unauthorized access to sensitive information Secrets exposed as environment variables visible via /proc
D — Denial of Service Making service unavailable Disrupting normal operations Fork bomb in a container exhausting node resources
E — Elevation of Privilege Gaining higher access Obtaining permissions beyond what was granted Container escape to host gaining root-level node access

For the KCSA exam, you must be able to classify a given scenario into the correct STRIDE category. Practice mapping real-world Kubernetes incidents to STRIDE.

STRIDE Mapped to Kubernetes Components

Each Kubernetes component is susceptible to specific STRIDE categories. The table below maps key components to their primary threat categories.

Component Spoofing Tampering Repudiation Info Disclosure DoS Elevation of Privilege
API Server ✅ Forged tokens ✅ Resource mutation ✅ Audit bypass ✅ Secret listing ✅ API flooding ✅ RBAC escalation
etcd ✅ Client impersonation ✅ Direct data modification ❌ ✅ Full cluster state exposure ✅ Storage exhaustion ✅ Grants full cluster control
Kubelet ✅ Anonymous auth ✅ Pod spec tampering ❌ ✅ Pod logs/exec access ✅ Node resource exhaustion ✅ Host namespace access
Container Runtime ❌ ✅ Image layer tampering ❌ ✅ Container filesystem access ✅ Runtime crash ✅ Container escape
Pod Network ✅ IP spoofing ✅ Man-in-the-middle ❌ ✅ Traffic sniffing ✅ Network flooding ✅ Lateral movement
Scheduler ❌ ✅ Scheduler policy tampering ❌ ✅ Scheduling decisions ✅ Scheduling starvation ✅ Force workload placement

This table is a powerful study tool — understanding which threats apply to which components helps you answer scenario-based questions quickly.

Threat Actors

A threat actor is anyone or anything that can exploit a vulnerability. In Kubernetes environments, common threat actors include:

External Attacker

  • Targets publicly exposed services (Ingress, LoadBalancer, NodePort)
  • Exploits unpatched vulnerabilities in applications or Kubernetes components
  • Scans for misconfigured dashboards, open API servers, exposed etcd

Malicious Insider

  • Has legitimate cluster access (developer, operator)
  • Abuses overly permissive RBAC roles
  • Exfiltrates Secrets or deploys unauthorized workloads
  • Hardest to detect because actions may look legitimate

Compromised Supply Chain

  • Malicious code injected into container images
  • Backdoored base images on public registries
  • Compromised CI/CD pipeline injecting unauthorized changes
  • Typosquatted package names (e.g., ngimx instead of nginx)

Malicious Tenant (Multi-Tenant Clusters)

  • One tenant attacking another in a shared cluster
  • Namespace breakout attempts
  • Resource starvation attacks against other tenants
  • Exploiting shared kernel in multi-tenant pods

The KCSA exam may present scenarios where you need to identify the most likely threat actor based on the attack pattern described.

Trust Boundaries in Kubernetes

A trust boundary is a line where the level of trust changes. Data crossing a trust boundary should be validated and secured. In Kubernetes, key trust boundaries include:

Cluster Boundary

  • Separates the cluster from the external network
  • Ingress controllers and LoadBalancers sit at this boundary
  • External traffic entering the cluster must be authenticated and authorized

Node Boundary

  • Separates individual worker nodes
  • Pod-to-pod communication across nodes crosses this boundary
  • Node compromise should not automatically compromise other nodes

Namespace Boundary

  • Logical isolation within a cluster
  • RBAC policies are scoped to namespaces
  • Namespaces are NOT a security boundary by default — network policies and RBAC must be configured to enforce isolation

Namespaces alone do not provide security isolation. Without NetworkPolicies and proper RBAC, pods in different namespaces can communicate freely.

Pod Boundary

  • Separates individual pods
  • Containers within the same pod share the same network namespace and can communicate via localhost
  • Secrets mounted in a pod are accessible to all containers in that pod

Container Boundary

  • Separates processes within a container from the host
  • Relies on Linux kernel features: namespaces, cgroups, seccomp, AppArmor
  • Weakest boundary — container escapes are a well-documented attack vector
┌─────────────────────────────────────────────────┐
│                 External Network                 │
│  ┌───────────────────────────────────────────┐  │
│  │            Cluster Boundary                │  │
│  │  ┌─────────────────────────────────────┐  │  │
│  │  │         Node Boundary               │  │  │
│  │  │  ┌───────────────────────────────┐  │  │  │
│  │  │  │     Namespace Boundary        │  │  │  │
│  │  │  │  ┌─────────────────────────┐  │  │  │  │
│  │  │  │  │    Pod Boundary         │  │  │  │  │
│  │  │  │  │  ┌───────────────────┐  │  │  │  │  │
│  │  │  │  │  │ Container Boundary│  │  │  │  │  │
│  │  │  │  │  └───────────────────┘  │  │  │  │  │
│  │  │  │  └─────────────────────────┘  │  │  │  │
│  │  │  └───────────────────────────────┘  │  │  │
│  │  └─────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

Attack Trees

An attack tree is a hierarchical diagram that breaks down a high-level attack goal into sub-goals and individual steps. Each node represents a condition or action required for the attack to succeed.

Example: Container Escape Attack Tree

Goal: Escape container to host
├── Path 1: Privileged container
│   ├── Deploy pod with privileged: true
│   └── Mount host filesystem
├── Path 2: Kernel exploit
│   ├── Identify kernel version
│   └── Run kernel exploit (e.g., Dirty COW)
├── Path 3: Docker socket mount
│   ├── Mount /var/run/docker.sock
│   └── Run docker commands on host
└── Path 4: /proc exploitation
    ├── Access /proc/sysrq-trigger
    └── Write to host /proc entries

Attack trees help security teams:

  • Visualize all possible paths to a goal
  • Identify the easiest (most likely) attack paths
  • Focus mitigations on the most critical paths
  • Communicate risks to non-technical stakeholders

MITRE ATT&CK for Containers

The MITRE ATT&CK framework provides a knowledge base of adversary tactics and techniques based on real-world observations. The Containers matrix is specifically relevant to Kubernetes.

Key tactics in the Containers matrix include:

Tactic Description Kubernetes Example
Initial Access Gaining a foothold Exploiting a vulnerable application, compromised image
Execution Running code Executing commands via kubectl exec, creating new pods
Persistence Maintaining access Creating a backdoor CronJob, modifying admission webhooks
Privilege Escalation Gaining higher access Exploiting hostPID, mounting host filesystem
Defense Evasion Avoiding detection Running in kube-system, deleting audit logs
Credential Access Stealing credentials Listing Secrets, accessing cloud IMDS
Discovery Understanding the environment Listing pods, services, RBAC roles
Lateral Movement Moving to other targets Accessing other pods via network, using stolen SA tokens
Collection Gathering data Reading ConfigMaps, accessing mounted volumes
Exfiltration Stealing data DNS tunneling, exfil via Ingress
Impact Causing damage Cryptojacking, resource exhaustion, data destruction

MITRE ATT&CK for Containers is a valuable reference, but for the KCSA exam, focus on understanding the tactics (the “why”) rather than memorizing specific techniques.

Threat Modeling Process for Kubernetes

When performing threat modeling for a Kubernetes deployment, follow these steps:

Step 1 — Define the Scope

  • Identify the Kubernetes components in scope (control plane, worker nodes, workloads)
  • List all external interfaces (Ingress, API server, node ports)
  • Document data flows between components

Step 2 — Identify Threats

  • Apply STRIDE to each component and data flow
  • Consider each threat actor (external, insider, supply chain)
  • Map threats to trust boundaries

Step 3 — Assess Risk

  • Likelihood: How easy is the exploit? Is the vulnerability publicly known?
  • Impact: What is the blast radius? Can the attacker pivot further?
  • Use a risk matrix (High/Medium/Low) to prioritize

Step 4 — Define Mitigations

  • Map each threat to a specific Kubernetes security control
  • Prioritize mitigations for High-risk threats
  • Consider defense-in-depth — multiple layers of protection

Step 5 — Validate

  • Verify mitigations are implemented correctly
  • Run security scanning tools (kube-bench, Trivy, Falco)
  • Schedule periodic reviews when architecture changes

Key Takeaways for the Exam

Concept What to Remember
STRIDE Six categories: Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege
Threat Actors External attacker, insider, supply chain, malicious tenant
Trust Boundaries Cluster → Node → Namespace → Pod → Container (namespace is NOT a security boundary by default)
Attack Trees Hierarchical breakdown of attack goals into sub-goals
MITRE ATT&CK Tactics and techniques framework for container threats
Threat Modeling Process Scope → Identify → Assess → Mitigate → Validate
  • STRIDE is the primary framework tested on the KCSA exam for threat categorization
  • Always think about who (threat actor), what (asset), how (attack path), and why (motivation)
  • Trust boundaries define where security controls must be enforced
  • Threat modeling is iterative — revisit when the system changes

Next: Kubernetes Attack Surface →

Updated:

You may also enjoy