Falco

Falco is the cloud-native runtime security engine: a CNCF Graduated project (created by Sysdig in 2016, donated to the CNCF in 2018) that has become the de facto standard for detecting anomalous behavior in Kubernetes clusters and Linux hosts. It observes system calls — the interface every application must use to talk to the kernel — parses them against a declarative rule set, and alerts on violations in real time. Source: Falco for Kubernetes Security — CKS Scenarios

Why Syscalls Are the Right Observation Point

Every action a workload takes — opening a file, spawning a shell, making a network connection — funnels through a syscall. An attacker can hide a process from ps or tamper with application logs, but they cannot act on the system without crossing the kernel boundary. Watching syscalls therefore gives Falco a complete and tamper-resistant view of runtime behavior, which is what makes it the anchor of Runtime Security.

Architecture: Kernel Drivers + User-Space Engine

Plane	Component	Role
Kernel space	eBPF probe (modern kernels) or kernel module (older kernels)	Captures syscall events and streams them through a ring buffer
User space	Falco engine	Enriches events with container/Kubernetes metadata, evaluates rules, emits alerts

Beyond raw syscalls, Falco ingests Kubernetes audit logs and plugin data (e.g., cloud provider API logs) to widen coverage. Enriched alerts can be emitted to stdout, syslog, gRPC, Prometheus, or HTTP — and via HTTP to Falcosidekick, a companion forwarder that fans alerts out to Slack, S3, Loki, and dozens of other sinks. Source: Falco for Kubernetes Security — CKS Scenarios

Rule Anatomy

Falco behavior is driven entirely by rules — YAML list items with five key fields:

- rule: Detect /dev/mem access
  desc: Alert when any process opens the physical memory device
  condition: fd.name = /dev/mem and evt.type in (open, openat)
  output: >-
    process=%proc.cmdline user=%user.name
    container_id=%container.id image=%container.image.repository
    pod=%k8s.pod.name
  priority: WARNING
  tags: [security, host]

• condition — a boolean expression over supported fields from the Falco documentation (the key reference to search, both in practice and in the CKS exam). Common fields: fd.name (full path when a file descriptor is a file), evt.type (syscall event type), proc.cmdline, container.id, k8s.pod.name.
• output — a free-form string with %field interpolations; this is what lands in your alert channel.
• priority — severity bucket (EMERGENCY down to DEBUG).

The default rule set ships hundreds of rules (e.g., Terminal shell in container); custom rules extend it, and default rules can be edited in place when a scenario demands a different output.

Deployment Model 1: DaemonSet on Kubernetes

The cluster-wide install runs Falco as a DaemonSet — one agent per node, matching Falco’s per-kernel observation model — typically via the falcosecurity/falco Helm chart:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco -n falco --create-namespace

Custom rules ship through a ConfigMap mounted into the Falco pods:

kubectl create configmap falco-custom-rules \
  --from-file=custom-rules.yaml -n falco
# kubectl edit daemonset falco → add volume (configMap) + volumeMounts
kubectl rollout restart daemonset/falco -n falco

Alerts are then read straight from the Falco pod logs — e.g. kubectl logs -n falco -l app.kubernetes.io/name=falco | grep /dev/mem — where Kubernetes metadata enrichment (k8s.pod.name, k8s.ns.name) identifies the offending workload directly. Source: Falco for Kubernetes Security — CKS Scenarios

Deployment Model 2: Host Install

Falco also runs as a plain Linux service (apt/rpm package) on a bare node — the model used for host-level detection and several CKS scenarios. Three files under /etc/falco/ matter:

File	Role
falco.yaml	Engine configuration — output channels (stdout, syslog_output, gRPC, HTTP), driver selection
falco_rules.yaml	The default rule set — edit in place only to change built-in rule outputs
falco_rules.local.yaml	Your custom rules — the correct place for new rules on a host install

Useful CLI pattern: falco -M <seconds> runs the engine for a bounded duration — handy for capturing a window of evidence to a file. On a host install there is no Kubernetes metadata enrichment, so a container ID from an alert is mapped back to a Pod with crictl ps | grep <id>.

Falco vs Admission Control (Kyverno)

Falco and Kyverno are complementary, not competing:

Dimension	Kyverno (admission)	Falco (runtime)
When it acts	Before a resource is persisted	After the workload is running
Posture	Preventive — blocks non-compliant manifests	Detective — alerts on suspicious behavior
Signal	API-server request	Kernel syscalls, audit logs
Example	Deny a Pod without resource limits	Alert when a running Pod reads /dev/mem

A hardened cluster runs both: admission control to keep bad configurations out, runtime detection to catch bad behavior that gets in. Both feed the defense-in-depth stack and the Operate stage of DevSecOps.

CKS Relevance

Falco is effectively a guaranteed topic on the CKS exam. The exam-ready skill set: locate rules (ConfigMap + DaemonSet volumes on K8s; falco_rules.local.yaml on hosts), construct conditions from the supported-fields doc, run falco -M, and trace an alert from container ID to Pod with crictl ps. See CKS Certification for the worked scenario patterns.

See Also

• Runtime Security — the security phase Falco anchors
• CKS Certification — the exam where Falco scenarios appear
• Container Security — Falco in the Detect layer of defense-in-depth
• Kyverno — the admission-time preventive counterpart
• Shift Left Security — runtime controls as the rightmost complement
• DevSecOps Fundamentals — the Operate stage where Falco runs
• Kubernetes DaemonSet — Falco’s one-agent-per-node deployment model
• Kubernetes ConfigMaps and Secrets — shipping custom rules via ConfigMap
• Helm — the chart-based cluster install path
• Kubernetes Logging and Monitoring — security-event stream as cluster telemetry
• Saiyam Pathak — creator of the scenario walkthrough source
• Falco for Kubernetes Security — CKS Scenarios — the source video

---

Tags: kubernetes falco runtime-security cncf ebpf devsecops security cks