Runtime Security Setup for Containers (Falco)

Runtime Security for Containers with Falco

Scanning images at build time is necessary but not sufficient. If an attacker gains a shell inside a pod through an application vulnerability, static scanning won't stop it. Falco works at runtime: it monitors system calls at the kernel level and alerts when something goes wrong—for example, when an nginx process suddenly calls execve("/bin/bash"). According to the IBM Cost of a Data Breach Report, the average cost of a cloud data breach is $4.24 million—and runtime security is critical to preventing such incidents. Downtime of critical applications can cost $5,000 per hour.

Imagine you use a node:14-alpine image, and an attacker exploits an RCE in Express to launch a reverse shell. No static analyzer will warn you—only runtime monitoring can. We set up Falco end-to-end in 1-3 days, including rule tuning for your stack. Clients report a 40% reduction in mean time to respond (MTTR), yielding substantial cost savings.

How Falco Detects Anomalies at the Kernel Level

Falco intercepts events via a kernel module or eBPF probe. In Kubernetes clusters, eBPF is the preferred option because it doesn't require loading a kernel module (often prohibited on managed nodes like GKE, EKS). With Falco 0.35+, a modern eBPF mode is available that works without a separate probe compiler.

Deployment via Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/..." \
  --set falcosidekick.config.slack.minimumpriority=warning

The Falco DaemonSet runs on each node—important because eBPF probes are tied to a specific kernel.

Why eBPF Is Preferred Over Kernel Module

Modern eBPF is 2x faster than legacy eBPF according to benchmarks. Our team uses it in 90% of projects.

Typical Problems Falco Solves

• Shell execution in production containers—the most common attack vector after vulnerability exploitation. Falco detects execve calls with bash/sh immediately.
• Configuration file changes—writing to /etc, /var/run/secrets, and other sensitive directories. The Write below etc rule triggers but requires tuning for legitimate init containers.
• Network exfiltration—running curl/wget/nc inside a container to send data out. The custom rule below catches such actions.

Custom rule for detecting curl/wget inside production containers:

# /etc/falco/rules.d/custom-rules.yaml
- rule: Unexpected outbound HTTP from container
  desc: Detects curl/wget execution inside containers
  condition: >
    spawned_process and container and proc.name in (curl, wget, nc, ncat) and not proc.pname in (package-manager, apt-get, yum)
  output: >
    Outbound HTTP tool in container (user=%user.name command=%proc.cmdline container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [container, network, mitre_exfiltration]

Rules are applied without restarting Falco—you can check active rules with falco --list.

Falcosidekick—Alert Routing

Falco itself writes events to stdout/syslog. For a production setup, you need Falcosidekick: it receives events and routes them to Slack, Telegram, PagerDuty, Elasticsearch, Loki, Kafka, or webhooks. Configuration via values.yaml:

falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/..."
      minimumpriority: "warning"
    elasticsearch:
      hostport: "http://elasticsearch:9200"
      index: "falco-events"
      minimumpriority: "notice"
    loki:
      hostport: "http://loki:3100"

In practice, it's useful to duplicate Critical events to both Slack and Elasticsearch/Loki—for quick response and for building Grafana dashboards showing incident frequency.

What Our Falco Setup Includes

1. Cluster audit—check kernel compatibility (kernel ≥ 5.8 for modern eBPF), review current security policies.
2. Falco deployment—install DaemonSet via Helm with optimal driver selection (eBPF / modern eBPF).
3. Rule tuning—suppress false positives for your stack (image names, namespaces, init containers).
4. Custom rules—write detections specific to your applications (e.g., forbidden tools, unusual network activity).
5. Alerting integration—connect Falcosidekick to Slack/PagerDuty/Loki with priority configuration.
6. Documentation and training—operational runbook, incident response checklist, team training.

Why Choose Us

We have been doing container security for over 10 years, completing 50+ Falco production deployments. Our engineers hold CKS and CKAD certifications. We offer a guarantee on the setup: free rule adjustments within the first month after deployment. Contact us for a consultation and project assessment.

Reducing False Positives

High false-positive rates are the main reason Falco is abandoned in production. Default rules can have up to 90% false positives: for example, Write below etc fires on init containers, and spawned_process on sidecars. The solution is custom exceptions. We craft rules considering your images and namespaces, keeping only truly dangerous events. After tuning, the false positive rate drops to 5-10%.

Conclusion

Runtime security is a mandatory layer for production clusters. Falco with eBPF provides kernel-level visibility without overhead. Order a turnkey Falco setup and keep your containers protected. Get a consultation for your cluster's Falco configuration.