Understand the concepts of Falco Talon

Why we created Talon

  • Custom-designed for immediate response to Falco events.
  • Implement response actions without coding.
  • User experience aligned with Falco, utilizing YAML for rule customization.
  • Enables configuration of action sequences triggered by Falco rules.
  • Provides structured logging complete with trace identification.
  • Simplified deployment through Helm charts.
  • Actions can be triggered on the below Falco criteria matches:
    • rule name (=)
    • priority (=, >=)
    • tags (=)
    • output fields (=, !=)


Falco Talon can receive the events from Falco or Falcosidekick:

┌──────────┐      ┌───────────────┐      ┌─────────────┐
│  Falco   ├──────► Falcosidekick ├──────► Falco Talon │
└──────────┘      └───────────────┘      └─────────────┘
┌──────────┐      ┌─────────────┐
│  Falco   ├──────► Falco Talon │
└──────────┘      └─────────────┘



Represents a possible threat or suspicious action detected by Falco and is sent to the outputs.


The rule define the criteria for linking the events with the actions to run.

See here to know more.


Each rule can sequentially run actions, each action refers to an actionner to know what to do.

See here to know more.


It defines what the action will do.

For example:

See here to know more.


It defines what outputs to notify with the result of the action.

See here to know more.


Falco Talon is able to de-duplicate the received events from Falco. It may happen Falco triggers the same rule multiple times for the same origin action (eg: change of and Falco Talon can de-duplicate these events to avoid to run several times the same action.

The de-deduplication function can also work in a multi pods in Kubernetes context, Falco Talon will create a lease to elect a leader that will aggregate all events from the other Falco Talon pods. In case of any issue, a new leader is automatically elected.

See here for the settings.