Concepts

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 (=, !=)

Architecture

Falco Talon can receive the events from Falco or Falcosidekick:

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

Keywords

Event

Represents a possible threat or suspicious action detected by Falco and forwarded to its outputs (file, http, program, stdout).

For example:

• BPF Program Not Profiled
• Service Account Created in Kube Namespace
• Exfiltrating Artifacts via Kubernetes Control Plane

Rule

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

See here to know more.

Action

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

See here to know more.

Actionner

It defines what the action will do.

For example:

• kubernetes:terminate
• kubernetes:networkpolicy
• kubernetes:script

See here to know more.

Notifier

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

See here to know more.

Output

Some actionners allow or require an output section. The output is the where target to store the resulting artifact that might has been created by the actionner. For example, the actionner kubernetes:log just allows to set an output to store the collected logs, if nothing is set, then they are printed in the stdout inside the log line; the kubernetes:download on its side requires an output to store the downloaded file from the pod.

See here to know more.

Context

The context is composed of elements from the original Falco event, from Falco Talon and other sources, that can be used to dynamically configure the actions. Some actionners allow also to specify extra sources of information.

See here to know more.

Deduplication

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 thread.id) 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.