Lion Cipher Lab

Detect Kubernetes control-plane threats from the audit log with Falco

• Cloud Security
• Advanced
• ~90 min
• Free · no account required

Why it matters

Kubernetes RBAC decides what a caller is ALLOWED to do; the API-server audit log records what actually HAPPENED — who called which API, as which service account or user, from which source IP, and whether it was permitted or denied. That is the single richest control-plane telemetry a cluster produces, and it is the only place many attacker moves are visible at all. When someone runs `kubectl exec` into a pod, reads a Secret, launches a privileged or hostPath pod to break out onto the node, or binds themselves to cluster-admin, those are API calls — they leave no syscall on your workloads…

What you'll learn

• the Kubernetes AUDIT LOG as a detection source: control-plane API events (who, as which RBAC subject, from which IP, allowed/denied) versus in-pod syscall behavior
• standing up a real API server locally with kind and wiring an audit policy + webhook backend so the apiserver streams audit events to Falco
• running Falco with the k8saudit plugin subscribed to that stream, distinct from Falco's host/container syscall source
• reading and choosing audit-policy levels (None / Metadata / Request / RequestResponse) and why Metadata detects a secret read without leaking its contents
• triggering real control-plane attacker TTPs on purpose (kubectl exec, secret read, privileged/hostPath pod, cluster-admin binding) and mapping each to the rule that fires
• authoring a custom k8saudit rule with ka.* fields and a lists/macros allowlist, and cutting a false positive by excluding a known service account
• the honest limits: audit logging is off by default on managed clusters, the log is high-volume/costly, and it sees API calls but never in-pod behavior
• the do-it-better path: ship audit events off-cluster to a SIEM, use the managed-cluster equivalents (EKS audit to CloudWatch), and pair the audit source with the syscall source

Steps in this lab

1. Two different Falco sources — say which one this is
2. Set up a scratch folder and confirm your tools
3. Write the audit policy — and choose Metadata for secrets on purpose
4. Point the API server at Falco with a webhook backend
5. Stand up the kind cluster with audit wired into the API server
6. Configure Falco with the k8saudit plugin and get the ruleset
7. Run Falco on the kind network and confirm the stream is live
8. Trigger real control-plane TTPs and watch the rules fire
9. Author a custom rule, then cut a false positive
10. The honest limits — and how a pro ships this

Open the full interactive lab →