August 20, 2026
9 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Static analysis and image scanning only protect your cluster before deployment; once a pod is running, you need Falco: Runtime Security for Kubernetes to detect actual malicious behavior like shell spawns or sensitive file access. While traditional web application security focuses on code-level vulnerabilities as discussed in my guide on securing websites and servers, containerized environments require kernel-level observability to catch zero-day exploits and insider threats in real time. This guide covers the practical engineering steps to deploy, tune, and operate Falco in production without drowning your team in false positives.
Quick answer: Falco: Runtime Security for Kubernetes is an open-source CNCF tool that monitors Linux syscalls via eBPF or kernel modules to detect anomalous container behavior at runtime. It uses customizable YAML rules to trigger alerts for security violations like unexpected process execution, network connections, or file modifications inside pods.
How does Falco architecture capture syscalls safely?
Understanding the data path is critical before deploying Falco: Runtime Security for Kubernetes in any environment where performance matters. Unlike log aggregators that parse text streams, Falco operates at the kernel boundary. In 2026, the recommended driver is eBPF (specifically the modern CO-RE driver), which attaches probes to syscall entry and exit points without loading a custom kernel module. This eliminates the risk of kernel panics that plagued earlier versions using the legacy falco.ko module.
The architecture follows a strict producer-consumer model. The kernel probe captures raw syscall events and applies initial filtering in-kernel to reduce overhead. Only events matching pre-compiled filter conditions are copied to userspace via a ring buffer. The Falco userspace process then evaluates these events against the loaded ruleset. If a rule matches, it generates an alert. This separation ensures that even under high load, the kernel-side instrumentation remains lightweight and bounded.
For teams managing infrastructure in Nepal or regions with limited bandwidth for shipping logs externally, this in-kernel filtering is especially valuable. You avoid saturating network links with benign syscall noise. The modern eBPF driver also supports field extraction directly in the probe, meaning metadata like container ID, process name, and user UID are resolved before reaching userspace. This reduces CPU overhead significantly compared to post-hoc enrichment.
How do you install Falco on Kubernetes in 2026?
Deployment has matured considerably. In 2026, the standard approach uses the official Helm chart (falcosecurity/falco) with the modern eBPF driver enabled by default. Avoid manual DaemonSet manifests unless you have specific compliance constraints preventing Helm usage. The following steps assume a Kubernetes cluster v1.28+ and Helm v3.14+.
Step 1: Add the repository and create namespace
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
kubectl create namespace falco-systemStep 2: Configure values for production
Create a falco-values.yaml file. Do not use defaults in production. Explicitly set the driver, resource limits, and output channels.
# falco-values.yaml
driver:
kind: modern_ebpf
modernEbpf:
leastPrivileged: true
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
falco:
rules_file:
- /etc/falco/falco_rules.yaml
- /etc/falco/rules.d/custom-rules.yaml
json_output: true
json_include_output_property: true
http_output:
enabled: true
url: "http://your-siem-collector.internal:8080/falco"
collectors:
containerd:
enabled: true
socket: /run/containerd/containerd.sockStep 3: Deploy and verify
helm install falco falcosecurity/falco \
--namespace falco-system \
--values falco-values.yaml \
--version 4.7.0
# Verify pods are running and driver loaded
kubectl get pods -n falco-system
kubectl logs -n falco-system -l app.kubernetes.io/name=falco | grep "Driver selected"A common mistake I've seen on client projects is forgetting to mount the correct container runtime socket. If your nodes use containerd (standard in 2026 K8s distributions), ensure containerd.socket path matches your node OS. On Ubuntu 22.04/24.04, it's typically /run/containerd/containerd.sock. Misconfiguration here causes Falco to miss container metadata enrichment, rendering alerts useless for forensics.
What are the most effective custom Falco rules?
Default rules generate excessive noise. Effective Falco: Runtime Security for Kubernetes requires tuning. Start by disabling noisy baseline rules and adding targeted detections for your workload. Rules use YAML with condition macros. Below is a production-tested pattern for detecting credential theft attempts in Laravel or PHP applications — a scenario relevant if you're building legal-tech portals handling sensitive documents.
# custom-rules.yaml
- rule: Sensitive File Access in Container
desc: Detect reads of .env, private keys, or config files outside expected paths
condition: >
evt.type = openat and
evt.is_open_read = true and
container.id != host and
fd.name rmatch "/var/www/html/.env" or
fd.name rmatch "/etc/shadow" or
fd.name rmatch "*/id_rsa"
output: "Sensitive file accessed (file=%fd.name container=%container.name proc=%proc.name user=%user.name)"
priority: WARNING
tags: [filesystem, credentials, laravel]
- macro: trusted_php_processes
condition: proc.name in (php-fpm, php, artisan, queue-worker)
- rule: Unexpected Shell Spawn in PHP Container
desc: Shells spawned by non-shell parent processes in web containers
condition: >
spawned_process and
container.image.repository contains "laravel-app" and
not trusted_php_processes and
proc.name in (bash, sh, zsh, dash)
output: "Shell spawned in PHP container (shell=%proc.name parent=%proc.pname container=%container.name)"
priority: CRITICAL
tags: [process, shell, webapp]Always validate rules locally before deploying. Use falcoctl test or run Falco in dry-run mode against captured pcap/syscall traces. Untested rules in production cause either missed detections or alert fatigue. For eCommerce platforms processing payments via eSewa or Khalti, add specific rules monitoring outbound connections to payment gateway IPs only — flag any other external connection from the payment processing pod as HIGH priority.
How does Falco compare to other Kubernetes security tools?
Choosing the right tool depends on your threat model. Falco excels at runtime behavioral detection but doesn't replace policy enforcement or vulnerability scanning. Below is a functional comparison based on production deployments in 2026.
| Capability | Falco | Kyverno / OPA Gatekeeper | Sysdig Secure | Cilium Tetragon |
|---|---|---|---|---|
| Runtime Threat Detection | ✅ Primary strength | ❌ Policy only | ✅ Commercial enhanced | ✅ Strong eBPF native |
| Admission Control | ❌ Not supported | ✅ Primary strength | ✅ Integrated | ⚠️ Limited |
| Custom Rule Language | YAML + Macros | Rego / CEL | Proprietary + Falco compat | TracingPolicy YAML |
| Performance Overhead | Low (eBPF filtered) | Negligible (admission) | Medium-High | Very Low (kernel enforced) |
| CNCF Status | Graduated | Incubating | Commercial | Sandbox |
| Best For | Breach detection, forensics | Compliance guardrails | Enterprise bundled platform | Network + syscall correlation |
In practice, many teams combine Falco with Kyverno. Kyverno prevents misconfigured pods from deploying (shift-left), while Falco detects when a correctly configured pod gets compromised at runtime (shield-right). For Nepali startups or SMEs with constrained budgets, the open-source Falco + Kyverno stack provides enterprise-grade defense without commercial licensing costs. If you're already evaluating cloud hosting options as covered in cloud hosting services comparison, factor in whether your provider offers managed Falco/Sysdig integration.
How do you handle Falco alert fatigue in production?
Alert fatigue kills security programs faster than missing detections. After deploying Falco: Runtime Security for Kubernetes, expect 2-4 weeks of aggressive tuning. Follow this operational workflow:
- Baseline Phase (Week 1-2): Run Falco in "log-only" mode. Aggregate alerts by rule name and container image. Identify top 10 noisiest rules.
- Suppress Known Good: Create exception lists for legitimate application behavior. Example: If your Laravel queue worker legitimately spawns
ffmpegfor video processing, add an exception rather than disabling the entire "unexpected child process" rule. - Priority Reclassification: Demote informational alerts to DEBUG. Reserve WARNING/CRITICAL for actionable incidents. Never send CRITICAL alerts to Slack channels without human triage capability.
- Enrichment Integration: Pipe Falco JSON to a SIEM or log aggregator. Correlate alerts with pod labels, deployment version, and user identity. Raw Falco output lacks business context needed for prioritization.
- Automated Response Hooks: For high-confidence rules (e.g., reverse shell detected), integrate with Kubernetes API to auto-isolate pods via NetworkPolicy or taint nodes. Start with manual response; automate only after 30+ days of stable detection accuracy.
Track your signal-to-noise ratio weekly. A healthy Falco deployment should have <5% false positive rate on WARNING+ alerts within 60 days. If not, revisit rule granularity. Consider splitting monolithic rules into workload-specific variants. For example, separate "shell spawn" rules for frontend pods vs backend worker pods — their acceptable behaviors differ fundamentally.
Implementing Falco: Runtime Security for Kubernetes Effectively
Falco: Runtime Security for Kubernetes delivers genuine value when treated as an operational discipline, not a set-and-forget checkbox. Deploy with the modern eBPF driver, invest heavily in rule tuning during the first month, integrate alerts with your existing observability stack, and measure false positive rates rigorously. Pair it with admission controllers for defense-in-depth. For teams building regulated applications in Nepal's legal or financial sectors, runtime detection is no longer optional — it's the last line of defense when preventive controls fail. If you need help architecting secure container workflows or integrating Falco with your existing Laravel/PHP infrastructure, reach out to discuss your specific requirements.
Frequently Asked Questions
Falco is an open-source cloud-native runtime security tool that monitors system calls to detect anomalous behavior in containers and Kubernetes pods. Unlike network firewalls or static scanners, it identifies threats like shell spawns, file modifications, or privilege escalation during execution. I treat it as essential observability infrastructure because containerized workloads are ephemeral and traditional host-based agents often miss pod-level context. It uses eBPF on modern kernels for low-overhead monitoring without modifying application code or requiring sidecar injection.
Admission controllers prevent non-compliant resources from entering the cluster at deployment time, while Falco detects malicious or unexpected behavior after workloads are running. They serve complementary purposes. On production clusters I manage, OPA enforces policy gates like image registries or resource limits, whereas Falco alerts when a running pod unexpectedly contacts a crypto-mining pool or writes to sensitive paths. Relying solely on admission control leaves you blind to post-deployment compromises, supply chain attacks, or insider threats within already-approved containers.
Falco daemonset typically consumes 100-300MB RAM and under 0.5 CPU cores per node with default rulesets on kernel 5.15+. Overhead depends heavily on syscall volume and rule complexity. High-throughput nodes processing thousands of syscalls per second may need resource limit adjustments. I always set explicit requests and limits to prevent noisy neighbors. The userspace fallback mode is significantly heavier than eBPF; verify your kernel supports modern eBPF probes before deploying to avoid performance degradation on busy production workloads.
Yes, Falco is CNCF graduated project licensed under Apache 2.0, completely free for commercial use. Costs arise from engineering time for tuning, log storage, and alert management infrastructure rather than licensing. Budget Rs 50,000-150,000 monthly (~USD 375-1,125) for managed logging backends if processing high event volumes across 20+ nodes. The software itself has no enterprise paywall, though vendors offer paid support and managed integrations. Self-hosted deployments only incur compute and storage expenses for the detection pipeline.
Falco requires kernel 4.14+ for basic eBPF support, but 5.8+ is recommended for stable CO-RE functionality and full feature parity. Kernel 6.x provides optimal performance. Older kernels force fallback to kernel module or userspace modes with higher overhead and limited capabilities. Always check uname -r before deployment. On Ubuntu 22.04 (kernel 5.15) and 24.04 (kernel 6.8), eBPF works reliably out of the box. CentOS 7 users must upgrade or accept degraded monitoring with the legacy kernel module driver.
Default rules are intentionally broad to catch known attack patterns, generating noise in legitimate workloads. Create custom override files disabling irrelevant rules for your stack rather than editing upstream configs. Use falcoctl to manage rule artifacts version-controlled alongside your IaC. Whitelist expected behaviors via append macros for specific namespaces or container images. On legal-tech portals I maintain, I disable terminal-in-container alerts for admin debugging pods but enforce them strictly on public-facing services. Tune iteratively over weeks using real traffic baselines, never silence rules globally without investigation.
Falco monitors system-level behavior, not application-layer payment transactions directly. However, it detects runtime anomalies indicating payment data exfiltration or unauthorized access to gateway credential files. For eSewa or Khalti integrations on Laravel applications, configure rules alerting on unexpected outbound connections from payment-processing pods or reads of environment variables containing API keys outside normal initialization. Combine with application logging for full audit trails. Falco provides infrastructure-layer assurance that complements PCI-DSS controls but does not replace transaction-level encryption or tokenization required by Nepali financial regulators.
Falcosidekick forwards events to Elasticsearch, Loki, Kafka, AWS S3, or SIEM platforms. Choice depends on existing infrastructure and retention needs. I prefer Loki for cost-efficient storage when teams already run Grafana stacks, keeping monthly costs under Rs 10,000 (~USD 75) for mid-sized clusters. Elasticsearch enables richer querying but demands more resources. Avoid stdout-only setups beyond development; unbuffered event loss during node restarts creates dangerous blind spots. Configure batching and retry logic in Falcosidekick to handle backend outages gracefully without dropping critical security signals.
Falco operates at syscall level and cannot decrypt TLS traffic natively. It sees socket operations, process executions, and file accesses regardless of encryption. To inspect encrypted payloads, pair with service mesh proxies like Envoy that terminate TLS before forwarding to Falco-monitored processes, or use eBPF-based tools like Beyla for L7 visibility. For most runtime security use cases, behavioral signals suffice without decryption. Detecting curl to suspicious domains or wget downloading binaries matters more than reading encrypted request bodies. Reserve deep packet inspection for specific forensic investigations rather than continuous monitoring.
No runtime detector catches every novel attack. Falco relies on known-bad patterns and anomaly heuristics, not signature matching alone. Zero-days exploiting previously unseen syscalls or obfuscated techniques may bypass current rules. Mitigate gaps through defense-in-depth: combine Falco with network policies, read-only filesystems, seccomp profiles, and regular vulnerability scanning. Maintain incident response playbooks assuming detection failures occur. After any breach, conduct retrospective analysis to identify missed signals and contribute new rules upstream. Treat Falco as one layer reducing mean-time-to-detect, not a silver bullet guaranteeing prevention.
Use falco-playground or local Docker environments with synthetic workloads mimicking production behavior. The official falcosecurity/testing repository provides validated test cases for standard rules. Create namespace-scoped staging deployments running representative applications, then trigger expected benign and malicious actions to verify alert accuracy. Never enable new ruleset versions directly in production without validation. On client projects, I maintain separate Falco configurations per environment with progressive rollout via GitOps. Monitor alert volume metrics for 48 hours post-deployment; sudden spikes indicate misconfiguration needing rollback before user impact occurs.
Yes, Falco supports all major managed Kubernetes distributions including EKS, GKE, AKS, and DigitalOcean. Managed services restrict kernel module loading, making eBPF probe mode mandatory. Verify node OS compatibility; Amazon Linux 2023 and Bottlerocket have different eBPF support matrices than Ubuntu. Some providers offer marketplace integrations simplifying deployment. Test thoroughly in non-production first since managed control planes limit troubleshooting access. On AWS EKS specifically, ensure VPC CNI allows Falco daemonset communication with Falcosidekick endpoints. Performance characteristics vary by instance type; benchmark before committing to large-scale rollouts.
Update rulesets monthly or immediately after critical CVE disclosures affecting your stack. Subscribe to falcosecurity/rules feed via falcoctl artifact follow for automated notifications. Pin specific versions in production rather than tracking latest blindly; breaking changes occur between minor releases. Schedule maintenance windows for updates since rule reloads briefly pause detection. Validate new rules against staging traffic before promotion. Outdated rules miss emerging threats, but unstable updates cause operational incidents. Balance freshness with stability based on your risk tolerance and change management capacity. Legal-tech platforms handling sensitive documents warrant conservative update cadences with extended testing periods.
Yes, Falco includes dedicated rules for common cryptominers detecting xmrig, kinsing, and similar binaries plus characteristic network connections to mining pools. Ransomware indicators include mass file encryption syscalls, deletion of shadow copies, and suspicious archive creation. These rules trigger on behavioral patterns rather than signatures, catching variants evading antivirus. False positives occur with legitimate batch processing or backup jobs; whitelist known-good workflows explicitly. In my experience, cryptomining detection provides highest immediate ROI since attackers frequently target misconfigured K8s clusters for resource theft. Respond automatically via webhook-triggered pod isolation to contain damage before manual triage.
Running without resource limits causes node instability during traffic spikes. Deploying kernel module mode on unsupported kernels crashes nodes silently. Ignoring Falcosidekick backpressure leads to event loss during backend outages. Disabling too many default rules creates false sense of security. Skipping eBPF verification wastes cycles troubleshooting incompatible drivers. Hardcoding secrets in ConfigMaps exposes credentials. Most critically, treating Falco as install-and-forget ignores necessary tuning. Production deployments require ongoing rule refinement, performance monitoring, and integration testing. Start conservative, measure baseline overhead, expand coverage incrementally, and document every exception for audit compliance.
