Kubernetes Threat Model (STRIDE)
Scope and method
This model applies STRIDE to each Kubernetes component, maps the threats to MITRE ATT&CK for Containers and the Microsoft Kubernetes threat matrix, and ranks them by exposure and impact.
- In scope: control plane (API server, etcd, scheduler, controller manager), nodes (kubelet, runtime, CNI), workloads (pods, RBAC, secrets), ingress and networking, supply chain (images, CI/CD, admission), and the cloud identity layer.
- Method: STRIDE per component across trust boundaries, then tactic mapping, then priority by likelihood (internet exposure, known exploitation) times impact (cluster-wide or single pod).
- Specification: The model rests on the published frameworks and recent CVEs.
The API server is the highest-privilege entry point; the dashed borders mark where authentication, network policy and credential scoping must hold.
STRIDE by component
Threat intelligence mapping
The strongest recent signal is ingress-nginx: several 2026 flaws let anyone who can edit Ingress objects run code in a controller that can read cluster secrets, and the project is now archived. Framework entries give the technique vocabulary; CVEs give the current exposure.
The Tech Insider report states there were no confirmed exploits for CVE-2026–4342 as of August 2026; treat that as a snapshot, not an all-clear.
Top risks and attack paths
Most realistic compromises chain a workload foothold, a stolen service account token, secret access, then node and cloud pivot; breaking the chain early with RBAC and Pod Security matters more than any single patch. Ranking is a judgement from exposure, known exploitation class and blast radius, and should be recalibrated against your own environment.
Mitigation priorities and detection
Fix identity and admission first, because they close ranks 1, 2 and 4; detection then covers what prevention misses.
- RBAC and tokens: remove wildcard and cluster-admin bindings, disable token automounting by default, use bound short-lived tokens.
- Admission control: enforce Pod Security Standards at restricted and block hostPath, privileged and runtime socket mounts; restrict who can create Ingress and webhook objects.
- Exposure: keep the API server, kubelet and dashboards off the public internet; turn off anonymous authentication.
- Ingress: inventory ingress-nginx, then migrate to a maintained controller; scope the controller’s secret access to what it needs.
- Network and egress: default-deny NetworkPolicy, egress allow-lists, metadata service hardening.
- Supply chain: signed images verified at admission, pinned digests, scanned base images.
- Secrets: encrypt etcd at rest, move secrets to an external store.
Sources:
Get Gaurav Sharma’s stories in your inbox
Join Medium for free to get updates from this writer.
· ATT&CK for Containers history
· eSecurity Planet on CVE-2026–24512
· Kubernetes post on CVE-2026–4342
