The cluster attack surface
Exposed API/kubelet/etcd, IMDS, and blast radius.
To defend a cluster you have to see it the way an attacker does: a set of exposed services and trust relationships, each of which can be a foothold or a pivot. This lesson maps the attack surface so the rest of the course — RBAC, admission, control plane, detection — has a target model to defend.
The exposed components
The highest-value targets are the control-plane and node services. The API server is the front door — every action flows through it, so exposure or weak authentication is critical. The kubelet API (10250) can, if anonymous auth is left on, allow exec into pods on that node. etcd holds all cluster state, including Secrets that are only base64-encoded by default, so read access to etcd or its backups is read access to every credential. The Kubernetes Dashboard, if exposed without auth or bound to an over-privileged service account, has led to real cryptojacking breaches. And from inside a pod, the cloud metadata endpoint (169.254.169.254) can hand over the node’s cloud IAM credentials.
# From a foothold, an attacker probes the reachable trust:curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ # cloud creds? (IMDS is plain HTTP)cat /var/run/secrets/kubernetes.io/serviceaccount/token # my SA tokenkubectl auth can-i --list # what can this token do?curl -sk https://<node-ip>:10250/pods # kubelet exposed?# Each answer opens (or closes) the next pivot: token → API → secrets → node → cloud.
Trust boundaries and blast radius
The key defensive insight is that a namespace is a soft boundary, not a strong one: without network policy, tightly-scoped RBAC, and node isolation, a compromise in one namespace can reach others. A single compromised node exposes every pod on it — and each pod’s mounted service-account token and secrets. Threat modeling means tracing, for each component, "what can an attacker who owns this reach next?" and then shrinking those blast radii deliberately.