Introduction to Falco Runtime Security
Falco is an open-source runtime security tool originally created by Sysdig and now a graduated project under the Cloud Native Computing Foundation (CNCF). It detects unexpected behavior in your systems by monitoring system calls and generating alerts based on configurable rules. Think of Falco as a security camera for your Linux hosts and Kubernetes clusters — it watches everything that happens at the kernel level and notifies you when something looks suspicious.
What is Falco Runtime Security?
🚀 Deploy your AI agent in 10 minutes
Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.
Try it free →Falco operates by instrumenting the Linux kernel to capture a stream of system call events. These events are then filtered and evaluated against a set of rules that define what constitutes normal versus anomalous behavior. When a rule matches, Falco generates an alert that can be forwarded to various destinations such as stdout, files, syslog, or external services like SIEM platforms.
Unlike traditional intrusion detection systems that rely on network traffic analysis or log parsing, Falco works at the syscall level. This gives it the ability to detect threats that other tools miss entirely — such as a process unexpectedly spawning a shell, a user accessing sensitive files they shouldn't touch, or a container mounting a host filesystem path it wasn't authorized to use.
Why Falco Matters for Runtime Security
Modern cloud-native environments face a critical gap: security tools excel at scanning images for vulnerabilities before deployment and enforcing network policies, but once a workload is running, visibility often drops to near zero. Attackers who bypass initial defenses or exploit zero-day vulnerabilities can operate undetected inside your environment for extended periods. Falco closes this gap by providing continuous runtime threat detection.
- Zero-day detection: Falco doesn't rely on vulnerability signatures. It detects behavioral anomalies, so even novel attacks trigger alerts.
- Insider threat monitoring: Whether malicious or accidental, unusual user activity inside containers or on hosts is captured immediately.
- Compliance enforcement: Falco helps meet regulatory requirements (PCI-DSS, SOC2, HIPAA) by maintaining an audit trail of suspicious runtime activities.
- Forensic data collection: Every alert includes rich metadata — process trees, user IDs, file paths, and timestamps — enabling rapid incident investigation.
- Cloud-native posture: Falco integrates natively with Kubernetes, Docker, and containerd, understanding concepts like pods, namespaces, and container IDs.
Core Concepts and Architecture
System Call Collection
Falco uses a kernel module (falco-kmod) or an eBPF probe (falco-bpf) to capture system calls. The kernel module approach works on virtually all Linux kernels, while the eBPF approach is preferred on newer kernels (4.x+) because it doesn't require loading a kernel module and is generally safer for production environments. Both methods feed a stream of structured events into Falco's userspace processing engine.
Falco's Internal Processing Pipeline
Inside the Falco daemon, events pass through several stages:
- libscap: The system call capture library that interfaces with the kernel module or eBPF probe. It collects syscalls and context information (processes, file descriptors, network connections) and writes them to a shared buffer.
- libsinsp: The state inspection library that enriches raw syscalls with higher-level context. It tracks process lifecycles, thread information, container metadata, and Kubernetes labels. This is what transforms a raw
open()syscall into "user root opened /etc/shadow inside pod payment-service." - Rules Engine: The enriched events are evaluated against the rule set. Rules are written in a custom language that supports logical operators, list membership checks, and macro expansion.
- Output Framework: When a rule fires, the alert is formatted and routed to configured outputs.
Falco Rules Language
Rules are defined in YAML files with a specific structure. Each rule contains a condition written in Falco's filtering language. Here are the key components of a rule:
- rule: Unexpected Shell in Container
desc: Detect any shell spawned in a container
condition: >
spawned_process
and container
and proc.name in (bash, sh, zsh, dash, ash)
and not proc.cmdline contains "kubectl"
output: >
Shell opened in container (user=%user.name, container=%container.name,
parent=%proc.pname, cmdline=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution]
The condition field is where the detection logic lives. It uses a rich set of fields including process names, file paths, network endpoints, user IDs, and Kubernetes metadata. The output field supports format specifiers that extract relevant context from the triggering event.
Installation and Setup
Installing Falco on a Linux Host
The simplest way to install Falco on a standalone Linux machine is via the official packages or the installation script:
# Option 1: Using the install script (recommended for quick start)
curl -fsSL https://falco.org/install.sh | bash
# Option 2: On Debian/Ubuntu
curl -fsSL https://falco.org/repos/falco-3.list | \
sudo tee /etc/apt/sources.list.d/falco.list
sudo apt-get update
sudo apt-get install -y falco
# Option 3: On RHEL/CentOS/Rocky Linux
curl -fsSL https://falco.org/repos/falco-3.repo | \
sudo tee /etc/yum.repos.d/falco.repo
sudo yum install -y falco
Configuring the Falco Service
After installation, Falco's configuration lives at /etc/falco/falco.yaml. Key configuration sections include:
# /etc/falco/falco.yaml - excerpt showing critical settings
# Choose between kernel module and eBPF
engine:
kind: ebpf # or "kmod" for kernel module
ebpf:
probe_file: /usr/share/falco/falco-bpf.o
# Output channels
outputs:
- stdout:
enabled: true
- file:
enabled: true
filename: /var/log/falco/falco.log
keep_alive: false
- http:
enabled: false
url: http://your-siembackend:8080/events
# Throttling controls
throttle:
rate: 1000 # max alerts per second
max_burst: 2000 # max burst of alerts
# Rule files to load
rules_files:
- /etc/falco/falco_rules.yaml
- /etc/falco/falco_rules.local.yaml
- /etc/falco/custom-rules/my_app_rules.yaml
Running Falco as a Systemd Service
# Enable and start Falco
sudo systemctl enable falco
sudo systemctl start falco
# Check status and recent alerts
sudo systemctl status falco
sudo journalctl -u falco -f
# View the alert log
tail -f /var/log/falco/falco.log
Deploying Falco on Kubernetes
In Kubernetes environments, Falco runs as a DaemonSet, deploying one pod per node. The official Helm chart is the recommended installation method:
# Add the Falco Helm repository
helm repo add falco https://falcosecurity.github.io/charts
helm repo update
# Install Falco with default settings
helm install falco falco/falco \
--namespace falco \
--create-namespace
# Install with eBPF driver (no kernel module required)
helm install falco falco/falco \
--namespace falco \
--create-namespace \
--set driver.kind=ebpf \
--set driver.ebpf.hostMountPath=/sys/kernel/debug
# Install with custom rules from a ConfigMap
helm install falco falco/falco \
--namespace falco \
--create-namespace \
--set-file customRules.rules=custom-falco-rules.yaml
Verifying the Deployment
# Check that Falco pods are running on all nodes
kubectl get pods -n falco -o wide
# View Falco logs from a specific pod
kubectl logs -n falco falco-xxxxx -f
# Trigger a test event to verify detection
kubectl run test-pod --image=alpine --restart=Never \
-n falco --rm -it -- sh -c "cat /etc/shadow"
Writing Falco Rules: A Deep Dive
Understanding Rule Syntax
A Falco rule consists of several mandatory and optional fields. The most important fields are rule, desc, condition, and output. Here is the complete anatomy:
- rule: Write Below Monitored Dir
desc: Detect any write to directories that are monitored
condition: >
evt.type in (open, openat, creat, mkdir, mkdirat, rmdir, unlink, rename)
and (fd.name startswith /etc or fd.name startswith /usr/local/bin)
and not proc.name in (dpkg, rpm, apt, yum, pacman)
output: >
File write below monitored dir (user=%user.name
command=%proc.cmdline file=%fd.name)
priority: ERROR
tags: [filesystem, mitre_persistence]
# Macros allow reusable condition fragments
- macro: in_container
condition: container.id != host
- macro: privileged_container
condition: >
container.privileged=true
or container.image.repository in (busybox, alpine)
# Lists group related values for cleaner conditions
- list: shell_programs
items: [bash, sh, zsh, dash, ash, fish]
- list: package_managers
items: [dpkg, rpm, apt, yum, pacman, dnf]
Common Syscall Fields Reference
When writing conditions, you have access to a comprehensive set of event fields. Here are the most commonly used ones:
# Process fields
proc.name # Process name (e.g., "bash", "curl")
proc.pname # Parent process name
proc.aname[2] # Grandparent process name (ancestor chain)
proc.cmdline # Full command line
proc.pcmdline # Parent command line
proc.exe # Path to executable
proc.pid # Process ID
proc.ppid # Parent process ID
proc.cwd # Current working directory
proc.loginuid # Login user ID (the original authenticated user)
proc.uid # Effective user ID
proc.gid # Effective group ID
# File fields
fd.name # File path being accessed
fd.directory # Directory portion of fd.name
fd.filename # Filename portion of fd.name
fd.type # Type: file, directory, pipe, etc.
fd.dev # Device number
fd.ino # Inode number
# Network fields
evt.rawres.fd.sport # Source port
evt.rawres.fd.dport # Destination port
evt.rawres.fd.sip # Source IP (as string)
evt.rawres.fd.dip # Destination IP (as string)
# Container/Kubernetes fields
container.id # Container ID
container.name # Container name
container.image # Full image reference
container.image.repository # Image repo (e.g., "nginx")
container.image.tag # Image tag (e.g., "latest")
container.privileged # Whether container runs in privileged mode
k8s.pod.name # Pod name
k8s.ns.name # Kubernetes namespace
k8s.sa.name # Service account name
Writing Effective Conditions
The condition language supports logical operators, comparison operators, and string matching. Here are practical pattern examples:
# Pattern 1: Detect execution of specific binaries
condition: proc.name in (curl, wget, nc, ncat, socat)
# Pattern 2: Detect network connections to suspicious IPs
condition: >
evt.type=connect
and (fd.sport=80 or fd.sport=443)
and not fd.sip in (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
# Pattern 3: Detect privilege escalation attempts
condition: >
evt.type in (setuid, setgid, setresuid, setresgid)
and proc.uid=0
and not proc.name in (sudo, su, runc)
# Pattern 4: Detect reading of sensitive files by unexpected processes
condition: >
evt.type in (open, openat)
and fd.name startswith /etc/shadow
and not proc.name in (sshd, passwd, cron, sudo)
# Pattern 5: Detect container escape attempts
condition: >
evt.type in (open, openat)
and fd.name startswith /proc/1/ns/
and container.id != host
and not k8s.ns.name in (kube-system)
# Pattern 6: Combining time-based conditions
condition: >
proc.name = bash
and proc.cmdline contains "curl"
and proc.cwd startswith /tmp
and fd.sport != 443
Practical Implementation Examples
Example 1: Detecting Reverse Shells
Reverse shells are a common post-exploitation technique. This rule detects processes that establish outbound connections while spawning an interactive shell:
- macro: reverse_shell_indicators
condition: >
proc.cmdline contains "/dev/tcp"
or proc.cmdline contains "socket.socket"
or proc.cmdline contains "pty.spawn"
or fd.sport = 4444
or fd.sport = 1337
or fd.sport = 5555
- rule: Reverse Shell Detected
desc: Detect reverse shell patterns in process and network activity
condition: >
spawned_process
and proc.name in (bash, sh, zsh, python, python3, perl, ruby, php, node)
and (reverse_shell_indicators
or (evt.type=connect and fd.sip != 127.0.0.1 and fd.sport != 443))
output: >
Potential reverse shell detected!
(command=%proc.cmdline, user=%user.name,
container=%container.name, ip=%fd.sip:%fd.sport)
priority: CRITICAL
tags: [reverse_shell, mitre_execution, mitre_command_and_control]
Example 2: Monitoring Sensitive File Access in Kubernetes
This rule set watches for unauthorized access to Kubernetes secrets and service account tokens:
- macro: k8s_sensitive_files
condition: >
(fd.name startswith /var/run/secrets/kubernetes.io
or fd.name startswith /etc/kubernetes
or fd.name contains "kubeconfig"
or fd.name contains "serviceaccount")
- rule: Access to Kubernetes Secrets Outside Kube-System
desc: Detect pods accessing k8s sensitive files outside kube-system namespace
condition: >
evt.type in (open, openat, read, readv)
and k8s_sensitive_files
and k8s.ns.name exists
and not k8s.ns.name in (kube-system, kube-public, falco)
and not proc.name in (kubelet, kube-proxy, coredns)
output: >
Unauthorized access to K8s secrets
(pod=%k8s.pod.name, namespace=%k8s.ns.name,
file=%fd.name, process=%proc.name, user=%user.name)
priority: CRITICAL
tags: [kubernetes, credential_access, mitre_credential_access]
- rule: Service Account Token Read by Unknown Process
desc: Detect reads of service account tokens by processes not in an allowlist
condition: >
evt.type in (open, openat, read)
and fd.name startswith /var/run/secrets/kubernetes.io/serviceaccount/token
and not proc.name in (java, node, python, ruby, envoy, pilot-agent)
and container.image.repository != "istio/proxy"
output: >
Service account token read (pod=%k8s.pod.name, proc=%proc.name,
image=%container.image.repository)
priority: HIGH
tags: [kubernetes, credential_access]
Example 3: Detecting Cryptocurrency Miners
Cryptojacking attacks deploy cryptocurrency miners inside containers. These rules detect common miner behaviors:
- list: known_miner_pools
items: [
"pool.minexmr.com", "xmrpool.eu", "mine.hashvault.pro",
"pool.supportxmr.com", "xmr.nanopool.org", "stratum+tcp"
]
- list: miner_process_names
items: [xmrig, xmr-stak, minerd, tsmgr, xmrig-notls]
- macro: cpu_intensive_behavior
condition: >
proc.cmdline contains "--cpu"
or proc.cmdline contains "max-cpu"
or proc.cmdline contains "threads"
- rule: Cryptocurrency Miner Detected
desc: Detect execution of known cryptocurrency mining software
condition: >
spawned_process
and (proc.name in (miner_process_names)
or proc.cmdline contains "stratum+tcp"
or proc.cmdline contains "mining"
or (proc.cmdline contains "xmrig" and cpu_intensive_behavior)
or (evt.type=connect and fd.rawres contains "stratum"))
output: >
Cryptocurrency miner detected!
(process=%proc.name, cmdline=%proc.cmdline,
container=%container.name, pod=%k8s.pod.name)
priority: CRITICAL
tags: [cryptojacking, mitre_impact, resource_hijacking]
Example 4: Container Escape Detection
Container escapes are among the most dangerous attacks. This comprehensive rule detects multiple escape techniques:
- macro: container_escape_syscalls
condition: >
evt.type in (mount, umount, chroot, clone, bpf, setns, unshare)
- macro: privileged_container_indicators
condition: >
container.privileged=true
or container.image.repository in (alpine, busybox, ubuntu)
- macro: suspicious_mount_paths
condition: >
fd.name startswith /proc/
or fd.name startswith /sys/
or fd.name startswith /dev/
or fd.name = /
or fd.name startswith /var/run/docker.sock
or fd.name startswith /var/run/crio/crio.sock
- rule: Container Escape via Mount
desc: Detect mounting host filesystem paths from within a container
condition: >
evt.type in (mount)
and container
and not container.privileged=true
and suspicious_mount_paths
and not k8s.ns.name in (kube-system)
output: >
Potential container escape via mount
(container=%container.name, mount=%fd.name,
process=%proc.name, user=%user.name)
priority: CRITICAL
tags: [container_escape, mitre_privilege_escalation]
- rule: Container Escape via Namespace Change
desc: Detect attempts to change Linux namespaces from within a container
condition: >
evt.type in (setns, unshare)
and container
and not container.privileged=true
and proc.cmdline contains "/proc/1/ns/"
output: >
Namespace manipulation detected
(container=%container.name, cmdline=%proc.cmdline,
syscall=%evt.type)
priority: CRITICAL
tags: [container_escape, namespace_manipulation]
Example 5: Custom Rule for Application-Specific Threats
Falco rules can be tailored to your specific application. Here's an example for a payment-processing application:
- rule: Unexpected Database Query from Web Pod
desc: Alert on direct database queries from web-facing pods
condition: >
evt.type=connect
and fd.sport=5432
and k8s.pod.name startswith "web-"
and not proc.name in (node, nginx, envoy)
and proc.cmdline contains "SELECT"
output: >
Direct database query from web pod
(pod=%k8s.pod.name, namespace=%k8s.ns.name,
process=%proc.name, cmdline=%proc.cmdline, db_host=%fd.sip)
priority: HIGH
tags: [application, database, sql_injection]
- rule: Payment Service Writing to Unexpected Files
desc: Detect payment service writing outside its expected directories
condition: >
evt.type in (open, openat, write, pwrite)
and k8s.pod.name startswith "payment-"
and fd.name exists
and not fd.name startswith /app/data
and not fd.name startswith /tmp
and not fd.name startswith /var/log
and not fd.name startswith /proc
output: >
Payment service wrote to unexpected path
(pod=%k8s.pod.name, file=%fd.name,
process=%proc.name, cmdline=%proc.cmdline)
priority: ERROR
tags: [application, file_integrity]
Integration with External Systems
Forwarding Alerts to a SIEM via HTTP
Falco can send JSON-formatted alerts to any HTTP endpoint, making integration with SIEMs and log aggregators straightforward:
# falco.yaml - HTTP output configuration
outputs:
- http:
enabled: true
url: "https://your-siem.example.com:8080/api/falco/events"
http_headers:
- "Authorization: Bearer your-api-token"
- "Content-Type: application/json"
mutual_tls:
enabled: true
ca_certificate: /etc/falco/certs/ca.pem
certificate: /etc/falco/certs/client.pem
key: /etc/falco/certs/client-key.pem
Integrating with Falco Sidekick for Rich Output Routing
Falco Sidekick is a companion daemon that receives Falco alerts and routes them to a wide variety of destinations including Slack, AWS Lambda, Elasticsearch, Kafka, and more:
# falcosidekick.yaml - configuration for multiple outputs
slack:
webhookurl: "https://hooks.slack.com/services/TXXXX/BXXXX/XXXX"
channel: "#security-alerts"
icon: "https://falco.org/img/falco-logo.png"
outputformat: text
elasticsearch:
hosturl: "http://elasticsearch:9200"
index: "falco-alerts"
suffix: "daily"
mutualtls: false
checkcert: false
kafka:
hosturl: "kafka:9092"
topic: "falco-events"
aws:
lambda:
functionname: "falco-processor"
accesskeyid: "AKIAXXXX"
secretaccesskey: "XXXX"
region: "us-east-1"
# Deploy Falco Sidekick alongside Falco
helm install falcosidekick falco/falcosidekick \
--namespace falco \
--set config.slack.webhookurl="https://hooks.slack.com/..." \
--set config.elasticsearch.hosturl="http://elasticsearch:9200"
Programmatic Integration with Falco's gRPC API
Falco exposes a gRPC API that allows you to subscribe to alerts programmatically. Here's a Python client example:
# falco_grpc_client.py - Subscribe to Falco alerts via gRPC
import grpc
import json
import sys
# Assuming you have the generated Falco protobuf stubs
# pip install falco-grpc-client (or generate from proto files)
import falco_output_pb2
import falco_output_pb2_grpc
def create_channel():
creds = grpc.insecure_channel_credentials()
channel = grpc.insecure_channel("localhost:5060")
return channel
def stream_alerts():
channel = create_channel()
stub = falco_output_pb2_grpc.FalcoOutputStub(channel)
# Subscribe to alerts
request = falco_output_pb2.OutputRequest()
for alert in stub.Outputs(request):
event = json.loads(alert.output)
print(f"Rule: {event.get('rule')}")
print(f"Priority: {event.get('priority')}")
print(f"Output: {event.get('output')}")
print(f"Time: {event.get('time')}")
print("-" * 60)
# Custom processing logic here
if event.get('priority') == 'CRITICAL':
trigger_incident_response(event)
def trigger_incident_response(event):
# Implement your incident response logic
print(f"[!] CRITICAL ALERT - Triggering automated response")
# e.g., pause deployment, isolate pod, notify on-call
if __name__ == "__main__":
stream_alerts()
Performance Tuning and Optimization
Understanding Falco's Performance Impact
Falco's performance overhead varies based on the driver type and the complexity of your rule set. In general, the eBPF driver imposes less overhead than the kernel module. Typical overhead ranges from 2-5% CPU on busy nodes when using eBPF with well-tuned rules. Here's how to measure and optimize:
# Check Falco's own resource consumption
kubectl top pods -n falco
# Monitor kernel event throughput
sudo falco --stats-interval 60
# Sample output:
# Events captured: 1245678
# Events dropped: 0 (0.00%)
# Events processed: 1245678
# Events matched (alerts): 234
Reducing Noise Through Rule Optimization
The most impactful optimization is writing precise rules that minimize false positives. Every rule evaluation consumes CPU cycles. Here are strategies:
# BAD: Broad condition that fires on every open() call
condition: evt.type=open
# GOOD: Targeted condition with specific paths and exclusions
condition: >
evt.type=open
and fd.name startswith /etc
and not proc.name in (dpkg, apt, yum, pacman, systemd, auditd)
# Use macro exclusions for system-level noise
- macro: system_management_processes
condition: >
proc.name in (systemd, systemd-logind, auditd, dbus-daemon,
polkitd, rtkit-daemon, packagekitd, snapd)
- rule: Sensitive File Open
desc: Opening of sensitive files by non-system processes
condition: >
evt.type in (open, openat)
and fd.name startswith /etc/shadow
and not system_management_processes
output: File %fd.name opened by %proc.name
priority: WARNING
Throttling and Rate Limiting
Falco provides built-in throttling to prevent alert storms from overwhelming your infrastructure:
# falco.yaml - Throttling configuration
throttle:
rate: 100 # Maximum alerts per second globally
max_burst: 500 # Maximum burst before throttling kicks in
# Per-rule throttling can be set in the rule itself
For per-rule throttling, you can embed limits directly in the rule definition:
- rule: High Volume Network Connections
desc: Detect unusual outbound connection rates
condition: >
evt.type=connect and fd.sport != 443 and fd.sport != 80
output: Connection to %fd.sip:%fd.sport
priority: INFO
# This rule can fire at most once every 60 seconds per container
throttle: 0.0166 # 1/60 = ~0.0166 events per second
Best Practices for Production Deployments
1. Use eBPF in Production
The eBPF driver is the recommended choice for production Kubernetes environments. It doesn't require loading a kernel module, which can be restricted by security policies, and it has a lower performance overhead. The eBPF probe runs in a sandboxed environment verified by the kernel's in-built verifier, making it safer than kernel modules.
# Helm deployment with eBPF
helm install falco falco/falco \
--namespace falco \
--create-namespace \
--set driver.kind=ebpf \
--set driver.ebpf.hostMountPath=/sys/kernel/debug \
--set falco.rulesFile=/etc/falco/falco_rules.yaml
2. Maintain a Custom Rules Repository
Don't rely solely on the default Falco rules. Build a version-controlled repository of custom rules tailored to your environment:
# Directory structure for custom rules
falco-custom-rules/
├── base/
│ ├── global_macros.yaml # Shared macros and lists
│ └── base_rules.yaml # Core detection rules
├── kubernetes/
│ ├── k8s_generic_rules.yaml # Generic K8s detections
│ └── k8s_network_rules.yaml # Network-specific K8s rules
├── applications/
│ ├── payment_service.yaml # App-specific rules
│ └── user_service.yaml
└── compliance/
├── pci_dss_rules.yaml # PCI-DSS required detections
└── soc2_rules.yaml
# Package as ConfigMap and mount in Falco
kubectl create configmap falco-custom-rules \
--from-file=falco-custom-rules/ \
-n falco \
--dry-run=client -o yaml | kubectl apply -f -
3. Implement Alert Severity Classification
Use Falco's priority system consistently to enable proper incident response workflows:
# Priority levels and their meaning
- rule: CriticalSecurityEvent
priority: CRITICAL # Immediate human response required (pager alerts)
- rule: HighSecurityEvent
priority: HIGH # Investigate within 30 minutes
- rule: WarningEvent
priority: WARNING # Review within 24 hours
- rule: InformationalEvent
priority: INFO # Logged for forensic purposes only
4. Combine Falco with Admission Controllers
Falco provides runtime detection, but you can strengthen your security posture by combining it with admission controllers that prevent dangerous configurations from being deployed in the first place. For example, use OPA Gatekeeper or Kyverno to reject pods with privileged security contexts, and let Falco catch any that slip through:
# Example Kyverno policy to deny privileged containers
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-privileged-containers
spec:
validationFailureAction: Enforce
rules:
- name: privileged-containers
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Privileged containers are not allowed"
pattern:
spec:
containers:
- =(securityContext):
=(privileged): "false"
5. Regular Rule Testing and Validation
Test your Falco rules in a staging environment before promoting to production. Falco provides a testing framework:
# Run Falco with a test event file to validate rules
falco --validate-rules /etc/falco/falco_rules.yaml
# Use falco-event-generator to create test events
git clone https://github.com/falcosecurity/event-generator
cd event-generator
go build
./event-generator run --all
# Verify that expected rules fire
tail -f /var/log/falco/falco.log | grep --color "CRITICAL\|ERROR"
6. Set Up Alert Aggregation and Deduplication
In large clusters, the same alert can fire hundreds of times. Implement deduplication in your alert pipeline:
# falcosidekick with alert deduplication
helm install falcosidekick falco/falcosidekick \
--namespace falco \
--set config.alertmanager.url="http://alertmanager:9093/api/v1/alerts" \
--set config.alertmanager.deduplicate=true \
--set config.alertmanager.deduplicatewindow=300 \
--set config.alertmanager.groupby="rule,priority,k8s.ns.name"
7. Monitor Falco Itself
Falco is a critical security component. If it stops running or drops events, you lose visibility. Set up monitoring for Falco's health:
# Prometheus metrics endpoint can be enabled in falco.yaml
metrics:
enabled: true
interval: 15s
output_rule: true
# Sample Prometheus scrape config
scrape_configs:
- job_name: 'falco'
static_configs:
- targets: ['falco-metrics.falco.svc:8765']
metric_relabel_configs:
- source