Detecting cluster attacks

Audit log, runtime rules, honeytokens.

Prevention closes the known paths; detection catches what gets through. In Kubernetes, two complementary sources — the API audit log and runtime tooling — cover the control plane and the workloads respectively, and tuning them for signal is what makes them usable.

The API audit log

The API server audit log is the cluster’s equivalent of cloud audit trails: the record of who did what, when, and from where. Driven by an audit policy, it captures the high-signal control-plane events — exec into pods, secret reads, new ClusterRoleBindings, webhook-configuration changes, service-account token creation — that map directly to ATT&CK’s credential-access, escalation, and persistence tactics. Tune the policy so valuable events are logged at Metadata or Request level while noisy ones are dropped: logging everything at full detail is expensive and buries the signal. Ship the log to a central, tamper-resistant store so a cluster compromise cannot erase its own trail.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # High-value: record the full request for these attack-adjacent actions.
  - level: Request
    verbs: ["create"]
    resources: [{ group: "rbac.authorization.k8s.io", resources: ["clusterrolebindings"] }]
  - level: Request
    resources: [{ group: "", resources: ["pods/exec", "secrets"] }]
  # Drop the noise so the signal is readable.
  - level: None
    resources: [{ group: "", resources: ["events", "endpoints"] }]
# Alert on: new ClusterRoleBinding, exec, bulk secret reads, webhook changes.

Runtime detection and honeytokens

The audit log cannot see inside a container, so pair it with runtime detection (Falco/Tetragon) to catch shells, escape attempts, and unexpected process/network behavior — control plane plus workload, together. Add honeytokens for high-confidence signal: a decoy Secret or a canary service-account token that nothing legitimate ever touches, so any read is near-certain evidence of an intruder rummaging for credentials. Route both audit alerts and runtime events into a pipeline that correlates and prioritizes by severity and asset, and map your detections back to ATT&CK so you can see, and close, the coverage gaps.