Falco

Falco is a runtime threat-detection engine for Linux hosts, containers and Kubernetes. It reads the system calls that processes make, enriches them with container and pod metadata, and checks every event against a set of rules, so a shell opened inside a production pod or a process that reads /etc/shadow produces an alert within moments. Falcosidekick takes those alerts and delivers them to the places where an operator already looks. The official docs at falco.org/docs own the rule syntax and the configuration reference.

What it is

Falco raises alerts and leaves blocking to other tools. It sits after admission control in the security chain: admission policy (Kyverno, Pod Security) decides what may start, image scanning (Trivy) reports what is inside an image, and Falco reports what a container actually does while it runs.

• Licence and governance. Apache 2.0. Sysdig created it and donated it to the CNCF in 2018. It reached Incubating in January 2020 and Graduated on 29 February 2024.
• Release line. Falco 0.45.0 shipped on 21 September 2026 (libs 0.26.0, driver 11.0.0). A 0.45.1 release candidate followed in October. 0.44.x shipped in May and June 2026.
• Recent breaking changes. 0.44.0 removed the legacy eBPF probe, the gVisor engine and the gRPC output and server. 0.45.0 evaluates rule conditions on raw field bytes, so rules that matched the Unicode replacement character with non-regex operators need review. 0.45.0 also dropped the container_engines key from the config schema; a config that still sets it logs a validation warning at startup.
• The family. falcosecurity on GitHub hosts Falco, the shared libs (libsinsp and libscap, which also power other tools), falcoctl (installs drivers, rules and plugins), the official rules repository, plugins (container, k8smeta, cloudtrail, okta and more), Falcosidekick and Falcosidekick-UI.
• Falcosidekick. A small Go daemon, also Apache 2.0. The current upstream release is 2.35.0 (31 August 2026). 2.32.0 (9 September 2025) added Logstash and Splunk outputs and moved the AWS outputs to aws-sdk-go v2, with no breaking changes listed.

How it works

Falco runs as a DaemonSet, one pod per node, because system calls are per kernel. On each node a kernel driver captures events into a ring buffer; userspace Falco reads them, attaches metadata and runs the rules engine. A rule is a filter condition over fields (evt.type, proc.name, fd.name, container.image.repository, k8s.ns.name and so on) plus an output template and a priority from debug to emergency.

Components

• Driver. The modern eBPF probe is the default and is compiled into the Falco binary using CO-RE, so nothing is built or downloaded per kernel. It needs BTF and BPF ring buffer support; the docs say kernels 5.8 and later are usually enough. The kernel module is the other option; it needs full privileges and cannot run with Linux capabilities alone. The legacy eBPF probe is gone since 0.44.
• Plugins. Plugins add event sources (AWS CloudTrail, Okta, GitHub audit logs, the Kubernetes audit log) and field extractors. Container metadata comes from the container plugin, which the Helm chart loads by default (collectors.containerEngine). The k8smeta plugin plus the k8s-metacollector add richer pod metadata and are off by default.
• Rules. Official rules ship at four maturity levels: stable, incubating, sandbox and deprecated. Only stable loads by default. Custom rules go in falco_rules.local.yaml or rules.d, and change existing rules with an override block (append or replace on condition, output, exceptions, enabled and so on).
• Outputs. Falco itself writes to stdout, a file, syslog, a program or an HTTP endpoint. With json_output on, the HTTP output sends one JSON document per event, and that is what Falcosidekick consumes.
• Falcosidekick. One HTTP listener in, many outputs out: Alertmanager, Loki, Elasticsearch, Slack, Teams, webhooks, Kafka, NATS, S3, and more. Each output has its own minimumpriority. It also exposes Prometheus metrics for the events it handles.

What Falcosidekick sends to Alertmanager

The Alertmanager output posts to /api/v2/alerts by default. Per the source:

• Labels alertname and rule both carry the rule name, source is falco, plus priority, eventsource, hostname and the sorted tags.
• Every output field with a string or number value becomes a label, with characters outside [a-zA-Z0-9_] replaced, so k8s.ns.name arrives as k8s_ns_name.
• severity maps from priority: emergency, alert and critical become critical; error and warning become warning; notice, informational and debug become information. customseveritymap overrides this.
• Annotations: summary is the rule name; info and description carry the rendered output line.
• extralabels are applied last and can overwrite any of the above.

When to use it

Reach for it when:

• A cluster runs workloads that face the internet and needs to know when one of them spawns a shell, opens a reverse connection, or writes to a system directory.
• Admission policy and image scanning are already in place and the remaining gap is behaviour at runtime.
• Alerts must land in an existing pipeline (Alertmanager, a SIEM, Slack) rather than in another dashboard.
• Compliance work asks for host-level intrusion detection evidence on Kubernetes nodes.

Skip it when:

• The goal is to block a process or syscall in the kernel. Falco only alerts; Tetragon or KubeArmor enforce.
• Nodes run a managed sandbox that hides the host kernel (for example serverless pods where no DaemonSet can run). gVisor support is gone since 0.44.
• Nobody will triage the alerts. Default rules on a busy cluster are noisy until tuned, and an untuned feed teaches people to ignore it.

At a glance

Core concepts

• Event — one system call (or plugin record) with fields.
• Rule — condition + output + priority + tags; can carry exceptions.
• Macro / list — reusable condition fragments and value lists that rules reference.
• Priority — emergency down to debug; outputs filter on a minimum.
• Driver — modern eBPF (default) or kernel module.
• Plugin — an extra event source or field extractor, loaded by falcoctl.
• Artifact — a rules or plugin bundle in an OCI registry, versioned by major (falco-rules:5).

Key facts

Item	Falco	Falcosidekick
Current release	0.45.0 (Sep 2026)	2.35.0 (Aug 2026)
Licence	Apache 2.0	Apache 2.0
Runs as	DaemonSet, one pod per node	Deployment
Kernel needs	BTF + BPF ring buffer for modern eBPF (5.8+ usually)	None
Privileges	Privileged or a set of capabilities (modern eBPF); full privileges for kmod	Unprivileged
Input	Syscalls, plugin sources	HTTP POST of Falco JSON on port 2801
Helm chart	falcosecurity/falco (Sidekick as a subchart)	falcosecurity/falcosidekick

Falco vs Tetragon

Aspect	Falco	Tetragon
Main job	Detection and alerting	eBPF security observability plus runtime enforcement
Policy language	YAML rules over high-level fields	TracingPolicy resources on kprobes, fentry/fexit, tracepoints, uprobes, USDTs and LSM BPF hooks
Rule library	Official rules at stable, incubating and sandbox maturity	A policy library of example policies paired with use cases
Can stop an operation	No	Yes: a Signal action (for example SIGKILL) and an Override action that changes a call's return value; the docs advise combining both to fully block
Event export	Falcosidekick, many outputs	JSON log file, stdout container log, tetra CLI or a gRPC API; a log shipper does the rest
Governance	CNCF graduated	A component of the Cilium project

How to integrate

Install Falco with the Sidekick subchart and the Alertmanager output. Enabling the subchart turns on json_output and points Falco's HTTP output at Sidekick automatically.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm upgrade --install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  -f falco-values.yaml

# falco-values.yaml
driver:
  kind: modern_ebpf            # default is "auto"; pin it so a node never falls back to kmod

falcosidekick:
  enabled: true
  config:
    alertmanager:
      hostport: "http://alertmanager.monitoring.svc:9093"
      endpoint: "/api/v2/alerts"
      minimumpriority: "warning"
      extralabels: "cluster:beta"   # lets Alertmanager group per cluster
      expiresafter: 3600            # resolve the alert an hour after the event

customRules:
  custom-overrides.yaml: |-
    - rule: Terminal shell in container
      exceptions:
        - name: debug_namespace
          fields: [k8s.ns.name]
          comps: [=]
          values:
            - [debug-tools]
      override:
        exceptions: append

Give Falco events their own Alertmanager route so they do not mix with infrastructure alerts:

route:
  routes:
    - matchers: ['source="falco"']
      receiver: security-email
      group_by: [cluster, alertname, k8s_ns_name]
      repeat_interval: 4h

Test the whole path without a real attack. Reading a sensitive file from a throwaway pod trips a stable rule:

kubectl run falco-test --rm -it --image=alpine -- sh -c 'cat /etc/shadow'
kubectl -n falco logs ds/falco -c falco | grep -i "sensitive file"

In the GL stack

Falco 0.45.0 runs on the beta and prod clusters, the two K3s clusters that serve paiddaily.io, sagedaily.io, builddaily.io and the other products. It uses the modern eBPF driver.

• Alert path. Falcosidekick 2.32.0 receives the events on each cluster and forwards them to Alertmanager on the management cluster. Alertmanager gives Falco events a route of their own, apart from the infrastructure alerts, and sends them as email through Amazon SES.
• Throttling. The Falco route groups by cluster, rule and namespace and repeats at most every 4 hours, so a noisy rule in one namespace produces a single email per window instead of one per event. The infrastructure routes repeat every 12 hours.
• Where it sits. Falco is the runtime layer of the security stack. Kyverno on the same two clusters handles admission (pod security, required labels, image registry rules), and Trivy Operator on beta scans running images and configs. Falco covers what those two cannot see: what a container does after it starts.
• Version note. Sidekick 2.32.0 is a year behind the current 2.35.0 upstream release; the upgrade is open, and the release notes are the place to check the Alertmanager output before it.

Gotchas

• The legacy eBPF probe is gone (0.44). Values that set driver.kind: ebpf fail after an upgrade. Use modern_ebpf or kmod.
• gRPC output is gone (0.44). Anything that consumed Falco events over gRPC (older Falco exporters, some UIs) must move to the HTTP output and Falcosidekick.
• Review custom rules for 0.45. Conditions now evaluate on raw bytes; a rule that matched the replacement character with = or contains may stop matching.
• Remove container_engines from configs. 0.45 dropped it from the schema and logs a warning at startup. Container metadata is configured through the container plugin (collectors.containerEngine in the chart).
• driver.kind: auto hides a fallback. On a node without BTF the loader can pick the kernel module, which needs full privileges and kernel headers. Pin the driver and check startup logs for "no BPF atomics on this kernel" and similar warnings.
• Rules update themselves. The chart runs falcoctl with artifact.follow on by default and follows falco-rules:5. A new upstream rule can start firing with no deploy. Disable follow and pin the artifact for reproducible behaviour.
• Every string field becomes an Alertmanager label. Fields such as proc.cmdline have high cardinality, so grouping on "all labels" yields one notification per command line. Group on a few chosen labels.
• Drop alerts are real. Under load the ring buffer can overflow; Falco then emits "Falco internal: syscall event drop" events, which Sidekick maps to critical by count. Treat them as lost visibility, and tune base_syscalls or buffer size instead of muting them.
• Alerts never resolve by default. With expiresafter: 0 Sidekick sets no end time, so Alertmanager resolves the alert only after its own resolve_timeout. Set expiresafter if "resolved" emails matter.

Risks

• Licence. Apache 2.0 for Falco, the libs, the rules and Sidekick. No open-core split; Sysdig sells a commercial product built on the same libs, but the open-source project does not depend on it.
• Project health. CNCF graduated with a regular release train (0.44 in May, 0.45 in September 2026) and an active plugin and rules ecosystem. Sidekick releases are less frequent but steady.
• Kernel coupling. Any driver is a privileged component in the kernel path. A kernel upgrade on the nodes can change BTF or helper availability; test Falco on the new kernel before a fleet-wide node upgrade.
• Privilege. Falco pods run privileged (or with broad capabilities). A compromise of the Falco pod is close to a compromise of the node; keep its image from the official registry and patch on release.
• Alert fatigue. The biggest operational risk is noise. Without exceptions for known-good behaviour, the stream gets muted and real events go unread.
• Lock-in. Low. Rules are plain YAML, and Sidekick outputs are standard protocols; switching the alert destination is one value.

Alternatives

• Tetragon — the Cilium project's eBPF security observability and enforcement component; pick it when a policy must stop an operation (Signal and Override actions) instead of only reporting it.
• Tracee — Aqua Security's Apache 2.0 eBPF runtime security and forensics tool with its own signature-based detections; pick it when forensics-style event capture matters or to keep runtime detection with the maintainer of Trivy.
• KubeArmor — a CNCF Sandbox runtime enforcement system; pick it for least-permissive (allow-list) policies per pod, container or node, enforced through AppArmor, SELinux or BPF-LSM.
• Kubernetes audit logs alone — enough when the concern is API activity (who created what) rather than process behaviour inside containers; Falco's k8saudit plugin can still consume them later.

Related

• Alertmanager — the route, grouping and SES email delivery for Falco events.
• Kyverno — admission policy on the same clusters.
• Trivy Operator — image and config scanning on beta.
• Prometheus — scrapes Falcosidekick's event metrics if wanted.
• Security layer overview — how the security services fit together.
• Falco documentation
• Falco releases on GitHub
• Falcosidekick Alertmanager output
• Falco Helm chart