ATT&CK for Kubernetes
The adversary playbook and coverage mapping.
MITRE ATT&CK for Containers gives the attacker’s playbook a shared vocabulary, which is what lets you measure detection coverage and reason about a real intrusion in structured terms rather than ad hoc.
Tactics against a cluster
The matrix walks the kill chain. Initial Access: an exposed API/kubelet, a vulnerable app, or a compromised image. Execution: exec into a pod, a malicious container. Persistence: a new ClusterRoleBinding, a mutating webhook, a CronJob or DaemonSet. Privilege Escalation: a privileged pod, RBAC escalation verbs, a node compromise. Defense Evasion: deleting audit config, running in an unmonitored namespace. Credential Access: stealing service-account tokens, reading Secrets, querying cloud metadata. Discovery: enumerating RBAC and services. Lateral Movement: hopping namespaces and nodes with stolen identities. Impact: cryptomining, data theft, ransom. Naming the technique makes it detectable and defensible.
# A real chain, tagged by tactic — this is how you reason during IR:## vulnerable web app (Initial Access)# └─ exec / RCE in pod (Execution)# └─ read SA token + secrets (Credential Access)# └─ kubectl to other ns (Lateral Movement / Discovery)# └─ create privileged pod (Privilege Escalation → node)# └─ new ClusterRoleBinding (Persistence)# └─ cryptominer / data theft (Impact)## For each step, ask: do we PREVENT it, and can we DETECT it?
From matrix to coverage
The practical use of ATT&CK is coverage measurement: for each technique relevant to your cluster, ask whether you prevent it (RBAC, admission, network policy) and whether you detect it (audit log, runtime rules). Gaps become a prioritized backlog — "we cannot currently detect a new ClusterRoleBinding" is an actionable finding. This structured approach beats a pile of disconnected alerts and gives the security program a map to work against, tying every later lesson (detection, admission, RBAC) back to a concrete adversary technique.