Falco

Falco#

Falco is the cloud-native runtime security project. Falco rules are a YAML DSL describing suspicious behavior at the kernel-syscall level, such as shells spawned in containers, sensitive file reads, privilege escalation, network connections to unexpected destinations.

CNCF graduated project; used in Kubernetes clusters, on Linux hosts, and inside cloud-native platforms.

The Mental Model#

Falco’s world is four simple kinds of object: events flowing in from kernel syscalls or audit logs, macros that name a reusable expression, lists that hold reusable values, and rules that fire alerts when an event matches. Everything else is composition over those four primitives.

  • Events, syscalls (and Kubernetes audit events, cloud-trail events) flow through Falco.

  • Macros, named, reusable expressions over event fields.

  • Lists, named sets of values (binaries, paths, ports).

  • Rules, expressions that classify events; if they match, an alert fires.

A Sample Rule#

- macro: container
  condition: container.id != host

- macro: shell_procs
  condition: proc.name in (sh, bash, zsh, dash, ash)

- list: trusted_images
  items:
    - "registry.internal/base"
    - "ubuntu:22.04"

- rule: Shell in Container
  desc: A shell was spawned in a container that should not have one
  condition: >
    evt.type = execve and evt.dir = <
    and container
    and shell_procs
    and not container.image.repository in (trusted_images)
  output: >
    Shell spawned in container (user=%user.name shell=%proc.name
    parent=%proc.pname container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [shell, container, mitre_execution]

A Falco rule is a YAML object with a fixed schema. The condition decides whether the rule fires; the output template formats the alert; tags map to ATT&CK; priority sets severity. Source determines whether the rule consumes syscalls, Kubernetes audit, or another plugin’s events.

  • rule, the human-named alert.

  • desc, description.

  • condition, a Falco condition expression. Combines syscall fields, macros, lists.

  • output, the alert message; %field placeholders are expanded.

  • priority, EMERGENCY / ALERT / CRITICAL / ERROR / WARNING / NOTICE / INFORMATIONAL / DEBUG.

  • tags, metadata; commonly ATT&CK tactic / technique IDs.

  • source, syscall (default), k8s_audit, aws_cloudtrail, custom plugin.

  • enabled, toggle without removing.

Condition Fields#

Falco exposes hundreds of fields per source. The most-used.

Field

Meaning

evt.type

syscall name (open, execve, connect)

evt.dir

> enter, < exit

proc.name / proc.exe running process name / path

proc.cmdline

full command line

proc.pname

parent process name

user.name / user.uid user

container.id /

container.image.repository

container context

fd.name

file path / socket

fd.sip / fd.sport

network: server IP / port

k8s.pod.name / k8s.ns.name Kubernetes context

Macros and Lists#

The two reuse primitives Falco rules lean on. Macros wrap a condition expression in a name; lists hold a set of values for in membership tests. Together they keep individual rules short and let one definition (e.g., “what counts as a read event”) propagate across dozens of rules.

Macros let you compose conditions.

- macro: sensitive_path
  condition: fd.name startswith "/etc/" or fd.name startswith "/root/"

- macro: read_event
  condition: evt.type in (open, openat, openat2) and evt.dir = > and evt.is_open_read = true

- rule: Sensitive File Read
  condition: read_event and sensitive_path and not container
  output: "Read of %fd.name by %proc.name (user=%user.name)"

Lists let you pin allowlists / denylists.

- list: known_admin_users
  items: [root, admin, operator]

Sources#

Beyond syscalls.

  • kubernetes audit, detect role escalations, hostPath usage, privilege flag changes.

  • aws cloudtrail, IAM policy changes, S3 bucket public ACLs, guard duty findings.

  • kafka / okta / github plugins, application-layer events.

Each source has its own field set.

Falco Sidekick#

Falcosidekick is the output router: takes Falco alerts and forwards to.

  • Slack / Teams / PagerDuty / OpsGenie.

  • Loki / Elasticsearch / Splunk / Sumo / Datadog.

  • AWS Lambda / GCP Cloud Functions for response automation.

  • Webhooks for anything else.

Falcoctl#

falcoctl is the package manager for Falco rules and plugins. Curated rule sets.

  • falco-rules, the built-in default.

  • falco-incubating-rules, new rules under evaluation.

  • Community / vendor packages for cloud-specific behaviors.

Detection Strategies#

The mental models that produce useful Falco rules. Default- allow with suspicious-activity flagging, default-deny with break-detection, ATT&CK mapping for coverage measurement, and allowlisting what’s normal in containers all play to the strengths of runtime detection.

  • Default-allow, baseline rules that flag suspicious activity.

  • Default-deny at the application layer, enforce a positive posture (ServiceAccount cannot exec into pods) elsewhere; Falco detects when expectations break.

  • MITRE ATT&CK mapping, tag rules with ATT&CK technique IDs; measure coverage.

  • Allowlist what’s normal, containers run specific binaries; lists describe the allowed set.

Tuning#

Real environments produce real false positives. Tuning patterns.

  • Image allowlist, not container.image.repository in (trusted_images).

  • Process allowlist, known maintenance scripts, package managers during build.

  • Container labels, exempt specific containers via Kubernetes labels (annotations.example.com/falco-exempt=true).

  • Time-of-day, separate rules during maintenance windows.

Architecture Notes#

  • Falco runs as a host agent (DaemonSet in Kubernetes).

  • Two drivers historically: kernel module and eBPF; modern preference is eBPF.

  • Plugins extend the source set.

  • No agent-on-pod required; Falco watches kernel events from the host.

Strengths#

The reasons Falco earned its CNCF graduation and a spot in most Kubernetes security stacks. Real-time kernel-level visibility, deep composition primitives, multiple sources beyond syscalls, and a managed ecosystem of curated rule sets all stack into a serious detection capability.

  • Real-time runtime detection, catches what static config can’t.

  • CNCF-graduated, mature, well-supported.

  • Composable, macros, lists, multiple sources.

  • Cloud-native, pairs with Kubernetes, EKS / GKE / AKS, cloud audit logs.

Weaknesses#

The flip side. Out-of-the-box noise demands tuning before production deployment; syscall tracing has measurable performance cost; eBPF needs kernel-version compatibility checks; and rule YAML at scale is verbose enough to demand the same code-review discipline as application code.

  • Noise out of the box, expect significant tuning.

  • Performance impact, syscall tracing has cost; eBPF mitigates most of it.

  • eBPF kernel-version dependencies, check compatibility.

  • YAML is verbose at scale; manage rules as code with CI / pull requests.

When (Not) to Use Falco#

  • Use for runtime security in Kubernetes / Linux hosts.

  • Use alongside an EDR for kernel-level coverage of behaviors EDRs may miss.

  • Use for cloud-trail / Kubernetes-audit detections without writing custom rule engines.

  • Don’t expect Falco to replace an EDR’s rich Windows endpoint features.

  • Don’t run without tuning, baseline noise levels first.

See Also#

Contents