Threat modeling Kubernetes — who, what, where, why

Threat modeling is the discipline of reasoning about a system before an incident, so the defences you ship match the attacks that actually happen. In Kubernetes, “the system” is not a single binary — it is a control plane, a node fleet, a runtime, a CNI, a workload identity system, a supply chain, and a set of humans. Threat modeling forces you to enumerate each piece, draw the trust boundaries, and rank the attacks that breach them. This lesson builds the model; the rest of Part LVI builds the controls.

The four questions

Every threat model answers four questions, in order:

1. What are we building? — the system, its components, its data flows.
2. What can go wrong? — what attacks are credible, who performs them, what they take.
3. What are we going to do about it? — controls we ship, ordered by leverage.
4. Did we do a good job? — how we measure, monitor, and test the controls.

Kubernetes answers question 1 with the well-known component diagram. Questions 2 and 3 are where the work is, and where most clusters under-invest.

Trust boundaries in Kubernetes

A trust boundary is a place where data crosses between trusting and untrusting domains. Inside Kubernetes there are six boundaries that every production threat model must cover:

flowchart LR
    A[Operator kubectl] -->|TLS, creds| B[(API server)]
    B -->|TLS, tokens| C[(etcd)]
    B -->|TLS, kubelet API| D[Kubelet on node]
    D -->|CRI gRPC| E[Container runtime]
    E -->|OCI pull| F[Image registry]
    B -->|admission webhook| G[Webhook service]
    H[Pod workload] -->|projected SA token| B
    H -->|CNI, host network| I[Node kernel]

Each arrow is a place an attacker may pivot. Each labelled boundary is a control surface. If your threat model does not enumerate every arrow, you are not modeling Kubernetes; you are modeling something simpler and more dangerous.

Actors

Who is in the model? Three categories:

• Humans — cluster operators (kubeadm-managed, on-call SREs), developers (CI/CD pipelines, kubectl users), attackers (phishing, stolen credentials, disgruntled employees).
• Workloads — Pods and their ServiceAccounts. Treat each ServiceAccount as an actor with the privileges granted by RBAC. The infamous “Tesla cryptomining” incident was a workload with too many privileges pivoting from a misconfigured dashboard.
• External systems — image registries, OIDC providers, admission webhooks, the cloud provider’s IAM, the corporate IdP. Each is a trust boundary crossing.

Assets

What are we protecting? In order of value to an attacker:

1. Secrets — database passwords, cloud IAM creds, third-party API tokens, TLS private keys. Direct value.
2. RBAC bindings — cluster-admin, namespace admin, ability to create Roles. Privilege escalation primitive.
3. etcd data — every object in the cluster. Reconstruction requires a full re-bootstrap.
4. Workload identity — ServiceAccount tokens used by workloads to talk to cloud APIs. Lateral movement.
5. Workload data — application data, customer data, logs. The reason the cluster exists in the first place.
6. Availability — a ransom-driven encryption or a cryptominer makes the cluster unavailable. Operational damage.

Attack tree (sketch)

Threat models use attack trees: the root is the goal (“compromise the cluster”), children are the sub-goals (“gain code execution on a node,” “steal Secrets,” “escalate RBAC,” etc.), leaves are concrete techniques.

mindmap
  root((Compromise cluster))
    Code execution on node
      Exploit workload CVE
      Container escape via privileged pod
      Host kernel exploit via volume mount
    Steal Secrets
      Read etcd via compromised API server
      Read Secret object via over-permissioned SA
      Sniff projected SA token from mounted volume
    RBAC escalation
      Bind to cluster-admin ClusterRole
      Create ClusterRoleBinding with wildcard
      Impersonate system:masters group
    Supply chain
      Push image with embedded backdoor
      Swap image tag to point at attacker image
      Skip image signature verification
    Network
      Pivot via default-allow NetworkPolicy
      Sniff pod-to-pod unencrypted traffic
      Reach API server from compromised node

Each leaf maps to a control. The tree is how you decide which controls to ship and how much to invest in each. If your cluster does not run untrusted code, “Exploit workload CVE” may matter less; if it runs multi-tenant untrusted code, it matters most.

Production failure modes

Three ways threat modeling goes wrong in real shops:

1. The model stops at the API server. Threats to kubelet, container runtime, kernel, and supply chain are not modeled because they are out of scope for the platform team. They are exactly the ones the attackers use.
2. The model assumes a benign workload. A multi-tenant cluster that runs untrusted code must model the workload as an attacker, not as a customer.
3. The model is never revisited. Kubernetes ships a release every four months. New attack surfaces appear (CRDs with elevated permissions, ephemeral containers, projected ServiceAccount token audiences, etc.). A threat model older than six months is stale.

Cross-course references

• The Linux course covers kernel attack surface and hardening — the foundation for the “Code execution on node” branch of the tree.
• The Observability course covers the audit log, the source of truth for “did the controls work?”
• The VyOS and OPNsense courses cover the network perimeter that the cluster sits inside; the threat model must include that boundary as well.

Quiz

Production discipline

A credible Kubernetes threat model names every trust boundary, every actor, every asset, and every attack goal. It is reused, not invented — start from the Kubernetes Overview of Cloud Native Security, layer on MITRE ATT&CK for Containers, and adjust for the cluster’s specific exposure (multi-tenant? internet-facing? regulated?). The model drives a defensive roadmap that is ordered by leverage, not by ease of implementation. A cluster without a threat model has no principled way to choose between shipping RBAC scoping or shipping supply chain controls; with one, the choice follows the attack tree.