Kubernetes Threat Model
Where clusters get attacked.
Kubernetes Threat Model is a free Cyber Security Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Kubernetes Is a Target
Kubernetes orchestrates containers across many nodes. It centralizes secrets, networking, and compute, so compromising the cluster can mean compromising every workload it runs.
- One API server controls the entire cluster.
- Nodes run many tenants' workloads side by side.
- Misconfiguration is far more common than core CVEs.
Cluster Architecture Recap
To threat-model, know the components.
- Control plane: API server, etcd, scheduler, controller-manager.
- Nodes: kubelet, container runtime, kube-proxy, pods.
- etcd stores all cluster state and secrets.
The API server is the single entry point; etcd is the data crown jewel.
The Attack Surface Map
Attacks target distinct layers.
- External: exposed API server, dashboards, ingress.
- Workload: a compromised app inside a pod.
- Identity: service account tokens and RBAC.
- Node: kubelet API, container escape to host.
- Supply chain: malicious images and dependencies.
Exposed Control Plane
An internet-reachable API server or kubelet with weak auth is a direct path to cluster takeover.
- Anonymous access enabled on the API server.
- The kubelet read/write API (port 10250) exposed.
- An open Kubernetes dashboard with admin binding.
# Probe an exposed kubelet for running pods
curl -sk https://NODE_IP:10250/pods
# Test anonymous API access
kubectl --insecure-skip-tls-verify --server https://API:6443 get podsThe In-Pod Foothold
The most common starting point is RCE in an application running in a pod. From inside a pod, attackers find:
- A mounted service account token at
/var/run/secrets/.... - Reachable internal services (no network policy).
- The API server, often resolvable as
kubernetes.default.
# From inside a pod: read the mounted SA token
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# Use it against the API
curl -sk -H "Authorization: Bearer $(cat .../token)" https://kubernetes.default/api/v1/namespaces/default/podsContainer Escape
Breaking out of a container onto the node yields all workloads on that host.
- Privileged containers can access host devices and escape.
- hostPID/hostNetwork/hostPath mounts widen the blast radius.
- A mounted Docker socket lets you start a privileged container.
- Dangerous capabilities (
SYS_ADMIN) enable escape.
# A privileged pod can mount the host filesystem and chroot to it
mount /dev/sda1 /mnt && chroot /mnt shetcd: The Secret Store
etcd holds the entire cluster state, including Secrets, which are only base64-encoded by default. Direct etcd access (often unauthenticated on misconfigured clusters) leaks every secret.
# Read all secrets from an exposed etcd
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-onlyLateral Movement in Clusters
Once inside, attackers pivot using cluster identity and networking.
- A permissive service account lets you create privileged pods.
- Flat pod networks (no NetworkPolicy) allow reaching any service.
- Scheduling a pod onto a target node enables node compromise.
Cloud Metadata From Pods
In managed clusters (EKS/GKE/AKS), pods may reach the node's cloud metadata service and steal the node's IAM/role credentials, bridging cluster compromise into the cloud account.
Defenses include IMDSv2, blocking metadata at the network layer, and using workload identity instead of node roles.
Mapping It With Tools
Tools automate cluster threat assessment.
- kube-hunter probes for exposed components.
- kube-bench checks CIS benchmark compliance.
- Peirates / kubeletctl exercise in-cluster attack paths.
# Assess attack surface
kube-hunter --remote API_IP
# CIS benchmark check on a node
kube-bench run --targets nodeDefensive Priorities
The threat model points to clear defensive priorities: lock down the API server, restrict RBAC, isolate pods, harden nodes, and secure the supply chain. The next lessons drill into each.
When testing, only attack clusters you are authorized for, and avoid destabilizing production workloads.
Quick Check
Confirm your Kubernetes threat-model basics.
Recap
You mapped where Kubernetes clusters get attacked.
- The API server and etcd are the central, highest-value targets.
- In-pod footholds leverage mounted SA tokens and flat networks.
- Privileged/hostPath pods enable container escape to the node.
- Managed clusters risk metadata-based cloud pivot.
Next: RBAC and service accounts.
Frequently asked questions
Is the “Kubernetes Threat Model” lesson free?
Yes — the full text of “Kubernetes Threat Model” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.
What will I learn in “Kubernetes Threat Model”?
Where clusters get attacked. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Cyber Security Academy?
No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Kubernetes Threat Model” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Cyber Security Academy lesson?
Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.