Kubernetes Security Events to Prioritize

Kubernetes generates an overwhelming volume of events, and most teams either alert on noise or miss the handful that signal an actual compromise. The events that matter are few and specific: someone exec-ing a shell into a running pod, a privileged or host-mounting container being created, and changes to cluster-admin RBAC. Those are the steps between a foothold and full cluster control. This guide ships the Falco rules and audit-log detections for the events worth your pager.

Kubernetes attacks map cleanly to MITRE ATT&CK’s container matrix: T1610 — Deploy Container, T1611 — Escape to Host, and T1078 — Valid Accounts for abused service-account tokens. The events below are where those techniques surface.

What makes a Kubernetes event worth alerting on?

Kubernetes is chatty — every reconcile loop, scale event, and health check is a log line. Alerting on volume guarantees fatigue. The signal comes from events that are rare in normal operations and necessary for an attack: getting a shell inside a container, deploying a pod configured to reach the host, or granting yourself cluster-admin. Those are not part of a healthy deploy pipeline.

It is the same rare-and-bad principle behind every darkpwn detection, applied to the cluster — the discipline from the detection engineering workflow carried into Kubernetes telemetry.

Which Kubernetes security events should you prioritize?

These map to the attacker’s path: deploy or access a container, configure it to reach the host, and escalate via RBAC. Cover this list before tuning anything else.

How to detect the events that matter

Two sources cover it: Falco for runtime (syscall-level) behavior, and the Kubernetes API audit log for control-plane actions.

A shell spawning inside a container is the runtime tell — the same service-process-spawns-a-shell logic that catches web RCE, applied to pods.

- rule: Shell Spawned In Container
  desc: A shell was executed inside a running container
  condition: >
    spawned_process and container
    and shell_procs and not known_shell_entrypoints
  output: >
    Shell in container (user=%user.name container=%container.name
    image=%container.image.repository proc=%proc.cmdline)
  priority: WARNING
  tags: [container, mitre_execution, T1610]

On the control plane, the audit log shows escape-enabling pod specs. In KQL (Sentinel / AKS diagnostics):

KubeAuditLog
| where Verb == "create" and ObjectRef.resource == "pods"
| where RequestObject contains "\"privileged\":true"
   or RequestObject contains "\"hostPID\":true"
   or RequestObject contains "\"hostPath\""
| project TimeGenerated, User.username, ObjectRef.namespace, SourceIPs

How to prevent the events you’re detecting

1. Enforce Pod Security Standards (restricted profile) via admission control to block privileged, host-mounting, and host-namespace pods by default.
2. Least-privilege RBAC — no wildcard verbs/resources, no anonymous bindings, and tightly held cluster-admin, per the NSA/CISA Kubernetes Hardening Guidance.
3. Limit exec to break-glass and audit every use.
4. Bind service-account tokens to their audience and rotate them; alert on off-cluster use.

Common Kubernetes detection mistakes

• Alerting on volume. Reconcile noise drowns the real events.
• Audit log only, no runtime. You miss in-container behavior; add Falco.
• No admission control. You detect privileged pods you could have blocked.
• Ignoring RBAC drift. A wildcard binding is a quiet path to cluster-admin.

Kubernetes security events checklist

1. Ship both the API audit log and Falco runtime events to the SIEM.
2. Alert on exec into pods and on privileged/host-mounting/host-namespace pod creation.
3. Alert on anonymous/wildcard RBAC bindings and cluster-admin changes.
4. Alert on service-account tokens used off-cluster.
5. Enforce Pod Security Standards (restricted) via admission control.
6. Apply least-privilege RBAC per NSA/CISA hardening guidance.
7. Correlate audit-log intent with Falco runtime behavior by pod.
8. Validate each detection by generating the benign event in a test cluster.

The takeaway

Kubernetes security monitoring is a short, high-signal list: exec into pods, escape-enabling pod specs, and cluster-admin RBAC changes, detected by correlating Falco runtime events with the API audit log and backed by Pod Security Standards. Continue with CloudTrail monitoring patterns and command injection detection, or browse the full Detection Engineering pillar.