Lion Cipher Lab
Enable Kubernetes audit logging and hunt in it
- Cloud Security
- Intermediate
- ~50 min
- Free · no account required
Why it matters
In AWS you have CloudTrail: a running record of who called which API, when, and whether it was allowed. Kubernetes has the exact same thing — the control-plane audit log, written by the API server — and almost nobody turns it on. That is the gap this lab fixes. RBAC (role-based access control) decides what a caller is ALLOWED to do; the audit log records what actually HAPPENED, which is a completely different and equally essential question. When a container is compromised through a leaked token or a vulnerable dependency, the attacker does not trip an alarm by existing — they trip one by…
What you'll learn
- understanding the Kubernetes control-plane audit log
- writing a Kubernetes audit policy (levels + stages)
- enabling apiserver audit flags on a kind cluster via kubeadmConfigPatches
- mapping host files into a kind node with extraMounts and extraVolumes
- generating security-relevant API events on purpose
- hunting a JSON audit log with jq (who read secrets, who exec'd into a pod, forbidden requests)
- recognising the cost/signal tradeoff of an audit policy
- knowing why audit logs must be shipped off-cluster to a SIEM
Steps in this lab
- The words first: API server, audit log, and the gap RBAC leaves
- Prove the gap: a plain kind cluster writes no audit log
- Write the audit policy: four levels, and why RequestResponse on secrets
- Stand up a kind cluster that actually writes the log
- Generate security-relevant events on purpose
- Hunt in the log with jq: who read secrets, who exec'd, what was forbidden
- The judgment: cost vs signal, ship it off-cluster, and what this log is NOT