Routing & automated response

Falcosidekick, Talon, isolate on critical.

A detection is only worth as much as the response it triggers. The last step of runtime detection is wiring Falco’s alerts into a pipeline that routes, correlates, and — for the clearest signals — acts automatically.

Route with Falcosidekick

Falcosidekick is the fan-out layer: it takes Falco’s output and forwards it to dozens of destinations — Slack/Teams for humans, a SIEM (Elastic, Sentinel, Chronicle) for correlation, Prometheus/Loki for metrics, and webhooks or serverless functions for automation. Routing by priority means a Notice goes to a log while a Critical pages on-call and triggers a playbook. This is what turns Falco from a per-node log into part of a coherent detection-and-response system.

# Falcosidekick config: high-severity → response function + page; rest → SIEM.
falcosidekick:
  config:
    slack:    { webhookurl: $SLACK,   minimumpriority: warning }
    elasticsearch: { hostport: es:9200 }          # everything, for hunting
    webhook:  { address: http://falco-talon,      minimumpriority: critical }
 
# Falco Talon (or a function) reacts to a critical event, e.g.:
#   on "Terminal shell in container" (critical) →
#     kubectl label pod $POD quarantine=true      # NetworkPolicy isolates it
#     kubectl delete pod $POD --grace-period=0     # evict after capture

Automated response, carefully

For unambiguous signals you can close the loop automatically: Falco Talon (or a sidekick-to-function flow) can label a pod so a NetworkPolicy isolates it, cordon a node, or evict a workload the moment a critical rule fires — containment in seconds rather than minutes. As with any enforcement, roll it out carefully: start by alerting, validate that the trigger is truly unambiguous, and only then let it act, so a false positive does not evict a healthy workload. Wrap the high-severity paths in rehearsed runbooks so the automated action is one you have practiced and trust.