Falco Runtime Security Guide: Deploy, Tune, Operate

Falco is easy to install and hard to run well: a default deployment produces alerts nobody owns, drops events under load and leaves its own configuration unprotected. This guide covers the operational side of Falco, the CNCF graduated runtime security project: choosing a driver and privilege level, managing the rules lifecycle with maturity levels and overrides, adding plugin data sources such as Kubernetes audit logs, routing alerts through Falcosidekick and Falco Talon, and measuring whether the sensor is healthy. It is written for platform engineers and detection engineers who already understand the runtime threat model. For the concepts behind eBPF sensors and runtime detection in general, start with the Container Runtime Security Guide; this page goes deeper on Falco itself.

This is an independent guide from NHI Mgmt Group, based on The Falco Project's public documentation as of November 2026. It is not sponsored or reviewed by The Falco Project. Product features change, so confirm settings against the project's current documentation.

Key takeaways

Pick the driver deliberately. The current falco.yaml lists four engine kinds (kmod, modern_ebpf, replay and nodriver); modern_ebpf is the default and can run with four capabilities instead of a fully privileged container.
Treat rules as a product with releases. Only maturity_stable rules ship with Falco; incubating and sandbox rules need explicit installation, and the project guarantees compatibility only between the latest rules and the latest Falco release.
Customise through overrides and exceptions, never by editing upstream files. The override key with append or replace keeps your changes separate so rule updates do not wipe them out.
Syscalls are only one source. Plugins add Kubernetes audit events, CloudTrail, Okta, GitHub and other identity-rich sources, which is where most credential misuse shows up.
Measure the sensor, not just the alerts. Event drops, output queue pressure and rules load errors tell you whether Falco is blind before an incident does.

What Falco is and how its parts fit together

Falco is a kernel monitoring and detection agent. It observes events such as system calls, evaluates them against rules, enriches them with container and Kubernetes metadata, and emits alerts that are meant to be analysed off-host in a SIEM or data lake. The project lives in the falcosecurity GitHub organisation, is licensed under Apache 2.0 and supports x86_64 and aarch64. The latest release recorded in the project changelog when this guide was checked (November 2026) was v0.45.2.

Component	Repository	Role in a deployment
Falco engine	falcosecurity/falco	The agent: loads rules, evaluates events, writes outputs. Configured in falco.yaml
Core libraries and drivers	falcosecurity/libs	Kernel instrumentation (kernel module and modern eBPF probe) and the event parsing state engine
Official rules	falcosecurity/rules	Rules files by maturity: falco_rules.yaml (stable), falco-incubating_rules.yaml, falco-sandbox_rules.yaml, falco-deprecated_rules.yaml
Plugins	falcosecurity/plugins	Extra event sources and field extractors, each with its own rules files
falcoctl	falcosecurity/falcoctl	Installs and follows rules and plugin artefacts; reads the running Falco version from the embedded web server
Helm charts	falcosecurity/charts	Kubernetes deployment of Falco and its ecosystem
Falcosidekick	falcosecurity/falcosidekick	Ecosystem daemon (MIT licence) that receives events from many Falco instances and fans them out to chat, SIEM, queues, object storage and response engines
Falco Talon	falcosecurity/falco-talon	Response engine (status incubating) that takes actions in Kubernetes and cloud when rules fire

Choosing a driver and privilege level

The engine.kind key in falco.yaml selects how events are collected, and only one engine can be set. The master branch falco.yaml lists kmod (kernel module), modern_ebpf (the CO-RE eBPF probe, the default), replay (reads a .scap capture file) and nodriver (no driver injected, used for debugging and for plugin-only deployments). The Container Runtime Security Guide explains the kernel-level trade-offs; the operational decisions are below.

Decision	Setting	When to choose it
Default syscall monitoring on modern kernels	engine.kind: modern_ebpf	Most clusters and hosts with BTF-enabled kernels; no per-kernel build to manage
Least privilege on Kubernetes	Helm: driver.kind=modern_ebpf and driver.modernEbpf.leastPrivileged=true	Where policy forbids privileged pods. The chart then adds only the BPF, SYS_RESOURCE, PERFMON and SYS_PTRACE capabilities instead of privileged: true
Older kernels without eBPF support	engine.kind: kmod	Legacy hosts only; needs a privileged container and a module matching the kernel build
Plugin-only collector	engine.kind: nodriver, Helm driver.enabled=false	A central Falco that only consumes Kubernetes audit, CloudTrail or other plugin sources
Forensic replay and rule testing	engine.kind: replay with replay.capture_file	Testing rule changes against recorded events in CI, or analysing a capture after an incident

Buffer sizing: engine.modern_ebpf.buf_size_preset (default 4, which is 8 MB per buffer on the documented index) and cpus_for_each_buffer (default 2, one ring buffer per CPU pair) control memory against drop risk. Raise the preset only after metrics show drops.
Syscall scope: base_syscalls.custom_set and base_syscalls.repair let you trim the monitored syscall set to what enabled rules need. The project warns that misconfiguring this can leave Falco unable to track processes, so change it only with replay testing.
Kernel visibility: the chart mounts /sys/kernel (or /sys/kernel/tracing or /sys/kernel/debug) for kernel-level access. Hardened node images sometimes block these paths, so test on the real node image, not a developer laptop.

Managing the rules lifecycle

Since rules version 2.0.0 the official rules are split by maturity, and every upstream rule carries its maturity level as its first tag. The rules repository describes the levels as follows: maturity_stable rules have been evaluated by experts with production experience and focus on universal detections such as reverse shells and container escapes; maturity_incubating rules address relevant threats for more specific use cases; maturity_sandbox rules are experimental; maturity_deprecated rules are kept as examples but no longer tuned. The project is explicit that maturity does not predict noise in your environment, and that adopters should treat the rules as examples and expect regular engineering effort.

Install, follow and load are three separate settings

Install: falcoctl.config.artifact.install.refs decides which rules artefacts (for example falco-rules, falco-incubating-rules) are downloaded at start-up.
Follow: falcoctl.config.artifact.follow.refs decides which artefacts are updated automatically while Falco runs. Auto-follow of incubating or sandbox rules in production means untested rule changes land without review; pin versions and promote through environments instead.
Load: rules_files in falco.yaml (falco.rules_files in Helm) decides which files the engine actually reads, in order. Your custom files must load after the upstream files they modify.

Customising without forking

Falco 0.37.0 and later support selective overrides. In a custom rules file loaded after the original, add an override block to a list, macro or rule naming each key and whether to append or replace it. The documented keys are: lists, items; macros, condition; rules with append, condition, output, desc, tags and exceptions; rules with replace, condition, output, desc, priority, tags, exceptions, enabled, warn_evttypes and skip-if-unknown-filter. Append and replace cannot be combined on the same key. The older append: true syntax is deprecated and the documentation says it will be removed in Falco 1.0.0. To switch a rule on or off, set enabled with an override of enabled: replace rather than redefining the rule.

Exceptions are the preferred way to express allowances. Each entry in a rule's exceptions list has a name, fields, comps (one operator per field, defaulting to = for a list of fields or in for a single field) and values as tuples. The documentation recommends thinking in terms of actor, action and target, and rejects process-name-only exceptions as too broad. In practice key exceptions on container image repository, namespace and Kubernetes service account, since process names are trivial to fake (ATT&CK T1036 Masquerading).

Customisation need	Mechanism	Example of a good scope
Allow a known tool to do something a rule flags	override: exceptions: append with a values tuple	Image repository plus namespace plus the file path it writes
Add your trusted registries or binaries to a list	override: items: append on the list	Internal registry hostnames used in container image macros
Raise or lower severity for your context	override: priority: replace	Raise a shell-in-container rule to CRITICAL for payment namespaces
Turn off a rule that does not fit	override: enabled: replace with enabled: false	Document the reason and the compensating control in the same file
Detection for your platform's invariants	New rule in your own file, tagged with ATT&CK IDs	"No package manager runs in production namespaces"

Matching order: rule_matching defaults to first, so only the first matching rule in load order fires for an event. Setting it to all evaluates every rule but costs performance; test before production.
Priority floor: the priority key loads only rules at or above the given level (default debug). Raising it to warning is a blunt noise control that also hides useful low-severity context; prefer tuning.

Adding identity-rich sources with plugins

Syscalls show what a process did on a node. Plugins add event sources that show who asked for it. The plugin registry includes k8saudit (plus managed-cluster variants k8saudit-eks, k8saudit-gke, k8saudit-aks and k8saudit-ovh), cloudtrail, gcpaudit, okta, github, gitlab, keycloak, salesforce, box, docker, journald, kafka and k8smeta and container for metadata enrichment. Plugin rules sit in the plugins repository and are outside the rules maturity framework, so review them as you would your own.

Kubernetes audit events: the k8saudit plugin defines the k8s_audit source and fields such as ka.user.name, ka.impuser.name, ka.verb, ka.target.name and ka.auth.decision. It receives events from the API server audit webhook backend, with an example open_params of http://:9765/k8s-audit. The plugin README recommends hosting the webhook backend outside the audited cluster. The detection logic itself is covered in the Kubernetes Audit Log Detection Guide.
Backpressure: the webhook refuses requests with HTTP 429 when its queue stays full for webhookEnqueueTimeout seconds (default 5), and the API server retries with back-off. Keep that value well below the API server's 30 second webhook timeout, as the README advises.
Cloud and SaaS identity: cloudtrail, gcpaudit, okta and github sources let one rule engine watch console logins, token creation and repository permission changes alongside workload behaviour. That matters because most container incidents end in a stolen cloud credential, not a kernel exploit.

Where identity fits

Falco itself handles several credentials, and its alerts are some of the best early evidence of credential theft from workloads.

Detecting credential access: upstream rules such as reads of sensitive files and searches for cloud credentials or private keys map to ATT&CK T1552.001 Credentials In Files, and container API access maps to T1552.007. Pair every hit with a review of what the pod's Kubernetes Service Account Token Guide scope and cloud workload identity could reach.
Falco's own service account: the chart creates a service account for metadata lookups. Keep it read-only and do not reuse it for response tooling.
Response credentials: Falco Talon actionners can terminate pods, apply network policies, cordon and drain nodes, run commands in pods and invoke AWS Lambda or GCP Cloud Functions. The identity running Talon is therefore a high-privilege non-human identity: scope its RBAC to exactly the actionners you enable, per namespace where possible. See the Kubernetes NHI Security Guide.
Output secrets: Falcosidekick holds webhook URLs, SIEM tokens and API keys for every output. Store them in a secrets manager and mount them, never in Helm values committed to Git.

Routing alerts and automating response

Falco has built-in outputs (stdout, syslog, file, program and http, all set in falco.yaml) and an embedded web server on port 8765 by default. For anything beyond a single host, the common pattern is Falco to Falcosidekick to many destinations, with Falco Talon taking actions.

Path	Key settings	Security notes
Falco http_output	enabled, url, ca_cert or ca_path, mtls, client_cert, client_key; json_output must be true for Falcosidekick	Keep insecure: false so the server certificate is verified; use mTLS between Falco and Falcosidekick
Falcosidekick fan-out	One endpoint for many Falco instances; outputs grouped as chat, alerting, logs, SIEM, object storage, queues, workflow and response engine	tlsserver.deploy and tlsserver.mutualtls enable TLS and mTLS for inbound events; mutualtlsclient settings hold certificates for outbound outputs
Falco Talon response	Rules that match on Falco rule names, priorities or tags and call actionners such as kubernetes:terminate, kubernetes:networkpolicy, kubernetes:label, kubernetes:cordon	Start with label and log actions, move to isolate (network policy) and terminate only for high-confidence rules
Captures for forensics	capture.enabled, capture.mode (rules or all_rules), capture: true on specific rules, max_file_size_mb	Sandbox feature; .scap files contain sensitive process and file data, so store them like evidence

The embedded web server exposes /healthz and /versions, and GET /reload; it listens on 0.0.0.0 by default with ssl_enabled false. Restrict it with a network policy so only probes and falcoctl reach it, or enable TLS.

How to implement

Define detection goals first: list the five to ten behaviours that must never happen in production (shell in container, write below binary directories, contact with the API server from application pods, crypto mining, access to cloud credential files). The project's own advice before deploying is to verify compatibility, define detection goals and plan SIEM integration.
Pilot on one non-production node pool: deploy with Helm using modern_ebpf, leastPrivileged=true, stable rules only, and json_output to your log pipeline. Enable metrics from day one.
Tune for two weeks: group alerts by rule, image and namespace. Write exceptions in a separate overrides file under version control, reviewed like code. Replay captured events through the changed rules in CI with engine.kind=replay before merging.
Add the Kubernetes audit source: run a separate plugin-only Falco (nodriver) for k8saudit or the managed variant, ideally outside the audited cluster.
Roll to production in rings: one node pool, then one cluster, then all. Keep incubating rules off until stable rules run with low false positives, as the rules maturity guidance recommends.
Introduce response gradually: notify only, then label, then network isolation, then termination for named rules. Every automated action must have an owner and a documented undo, such as removing the label or deleting the generated policy.
Rollback: keep the previous rules artefact version pinned and the previous Helm release available; rolling back Falco or its rules is a helm rollback, and response can be disabled by removing Talon rules without touching detection.

Decision guidance

Small teams: stable rules, Falcosidekick to one SIEM or chat channel, no automated response. Spend effort on exceptions and on a weekly review of the top five noisy rules.
Large platforms: central Falcosidekick per environment with mTLS, separate plugin collectors per cluster, rules promoted through dev, staging and production as versioned artefacts, and Talon for isolation of high-confidence detections.
Managed Kubernetes: confirm the node image allows eBPF and the required capabilities; use the provider-specific k8saudit plugin for control plane audit logs, since you cannot reach the API server's audit files.
Regulated workloads: enable captures for critical rules so evidence exists after the pod is gone, and route alerts to an immutable store.

Detection and measurement

Falco's metrics framework (metrics.enabled, off by default) emits falco. and scap. fields at an interval and can feed Prometheus through webserver.prometheus_metrics_enabled. syscall_event_drops raises log and alert actions when drops exceed a threshold (default 0.1, or 10 percent, in the last second).

Coverage: percentage of nodes running a healthy Falco pod (target 100 percent; alert on any DaemonSet gap).
Event drop rate: kernel drop percentage per node; sustained drops mean blind spots that an attacker can exploit by generating noise.
Alert precision: share of alerts in the last 30 days that led to action or a confirmed benign exception; aim to improve month on month.
Exception hygiene: number of exceptions without an owner or review date (target zero) and the age of the oldest.
Rules currency: days between an upstream rules release and its promotion to production.
Time to response: median minutes from a critical Falco alert to containment, automated or manual.

Common failure patterns

Alerts with nowhere to go: Falco logs to stdout and nobody reads them. In the Tesla Kubernetes Cryptojacking case, miners ran inside a cluster after credentials were exposed; runtime detection only helps if a mining process or unexpected outbound connection reaches someone who acts.
Editing upstream rules files: changes vanish at the next falcoctl update. Use overrides in your own file.
Exceptions on process name alone: attackers name their binary after an allowed one. Scope by image, namespace and service account.
Ignoring drops: a node under load silently drops events, and the threshold alert is rate limited to one message every 30 seconds by default. Watch the metric, not the log line.
Auto-following sandbox rules in production: rule changes from the main branch can break compatibility; the project recommends rules from release branches only.
Over-privileged response: Talon or a custom webhook with cluster-admin becomes the most valuable credential in the cluster.

Framework mapping

Framework	Reference	How Falco contributes
NIST CSF 2.0	DE.CM-09, DE.AE-02	Monitoring of runtime environments and analysis of adverse events
NIST SP 800-53 Rev. 5	SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting	Host and container behaviour monitoring, audit event analysis through plugins
CIS Controls v8.1	Control 8 Audit Log Management, Control 13 Network Monitoring and Defense	Centralised runtime and audit telemetry with alerting
ISO/IEC 27001:2022	Annex A 8.16 Monitoring activities	Monitoring for anomalous behaviour of systems and applications
MITRE ATT&CK	T1611 Escape to Host, T1609 Container Administration Command, T1610 Deploy Container, T1059.004 Unix Shell, T1496 Resource Hijacking, T1613 Container and Resource Discovery	Behaviours the stable and incubating rules are written to detect; tag your own rules with the same IDs

Practitioner checklist

Run modern_ebpf with the least privileged capability set where the kernel allows it.
Pin rules artefact versions; promote incubating or sandbox rules only after testing.
Keep all customisations in a version-controlled overrides file using override and exceptions.
Scope exceptions by image, namespace and service account, never by process name alone.
Add the Kubernetes audit plugin through a separate collector outside the audited cluster.
Send JSON output over mTLS to Falcosidekick and store output credentials in a secrets manager.
Enable metrics and alert on event drops and missing DaemonSet pods.
Restrict the embedded web server on port 8765 with network policy or TLS.
Give any response engine the narrowest RBAC its enabled actionners need, with a documented undo.
Replay recorded events against rule changes in CI before production rollout.

Falco Runtime Security Guide: Deploying, Tuning and Operating Falco in Production