What Is Runtime Security with Falco in Kubernetes?

Detailed Answer

Falco is a CNCF graduated project that provides runtime threat detection for containers and Kubernetes. While admission controllers prevent misconfigured workloads from being deployed, Falco monitors what actually happens inside running containers — detecting attacks, compromises, and policy violations in real time.

Why Runtime Security Matters

Static analysis and admission policies cannot catch:

• A legitimate container being exploited via a vulnerability
• An attacker spawning a reverse shell inside a running Pod
• Cryptomining processes starting after deployment
• Sensitive files being read by unexpected processes
• Unexpected outbound network connections

Falco detects these by monitoring system calls at the kernel level.

How Falco Works

Container Process → System Call → Kernel
                                    ↓
                              eBPF probe (or kernel module)
                                    ↓
                              Falco engine → Rules evaluation
                                    ↓
                              Alert (stdout, syslog, webhook, Slack)

Installation

# Install with Helm using eBPF driver
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true

Falco runs as a DaemonSet, one Pod per node:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: falco
  namespace: falco
spec:
  selector:
    matchLabels:
      app: falco
  template:
    metadata:
      labels:
        app: falco
    spec:
      hostPID: true
      hostNetwork: true
      containers:
        - name: falco
          image: falcosecurity/falco-no-driver:0.37.0
          securityContext:
            privileged: true
          volumeMounts:
            - name: proc
              mountPath: /host/proc
              readOnly: true
            - name: dev
              mountPath: /host/dev
            - name: rules
              mountPath: /etc/falco
          resources:
            requests:
              cpu: "100m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: dev
          hostPath:
            path: /dev
        - name: rules
          configMap:
            name: falco-rules

Falco Rules

Rules define what behavior to detect. Each rule has a condition, output, and priority:

- rule: Terminal shell in container
  desc: Detect a shell spawned in a container
  condition: >
    spawned_process and
    container and
    shell_procs and
    proc.pname != healthcheck
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
     shell=%proc.name parent=%proc.pname
     image=%container.image.repository
     pod=%k8s.pod.name ns=%k8s.ns.name)
  priority: WARNING
  tags: [container, shell, mitre_execution]

- rule: Read sensitive file
  desc: Detect reads of sensitive files (passwords, keys)
  condition: >
    open_read and
    container and
    sensitive_files and
    not proc.name in (allowed_sensitive_readers)
  output: >
    Sensitive file read in container
    (user=%user.name file=%fd.name
     container=%container.name
     image=%container.image.repository)
  priority: WARNING
  tags: [container, filesystem, mitre_credential_access]

- rule: Unexpected outbound connection
  desc: Detect outbound connections to unexpected destinations
  condition: >
    outbound and
    container and
    not (fd.sip in (allowed_outbound_ips) or
         fd.sport in (allowed_outbound_ports))
  output: >
    Unexpected outbound connection
    (user=%user.name command=%proc.cmdline
     connection=%fd.name
     container=%container.name
     pod=%k8s.pod.name ns=%k8s.ns.name)
  priority: NOTICE
  tags: [container, network, mitre_command_and_control]

Common Built-in Rules

| Rule | Detects | |------|---------| | Terminal shell in container | Interactive shell access (kubectl exec attack) | | Write below /etc | Configuration file tampering | | Read sensitive files | Access to /etc/shadow, SSH keys | | Unexpected process | Processes not in the container's baseline | | Outbound connection | Network connections to unexpected destinations | | Privileged container started | Containers running with privileged flag | | Kubernetes client tool in container | kubectl, curl to API server from within a Pod | | Container drift detected | New executables that were not in the original image |

Custom Rules

Create rules specific to your applications:

- rule: Crypto mining detected
  desc: Detect cryptocurrency mining processes
  condition: >
    spawned_process and
    container and
    (proc.name in (xmrig, minerd, cpuminer, cgminer) or
     proc.cmdline contains "stratum+tcp" or
     proc.cmdline contains "pool.minergate")
  output: >
    Crypto mining detected
    (process=%proc.name cmdline=%proc.cmdline
     container=%container.name
     pod=%k8s.pod.name ns=%k8s.ns.name)
  priority: CRITICAL
  tags: [container, cryptomining]

Alert Outputs with Falcosidekick

Falcosidekick routes Falco alerts to various destinations:

# Falcosidekick configuration
config:
  slack:
    webhookurl: "https://hooks.slack.com/services/xxx"
    minimumpriority: "warning"
  elasticsearch:
    hostport: "http://elasticsearch:9200"
    index: "falco"
  prometheus:
    listen: ":9101"

Kubernetes-Aware Context

Falco enriches alerts with Kubernetes metadata:

• %k8s.pod.name — Pod name
• %k8s.ns.name — Namespace
• %container.image.repository — Container image
• %k8s.deployment.name — Owning Deployment

This context makes it possible to correlate runtime alerts with specific workloads.

Integration with Response Automation

Combine Falco with response tools:

Falco Alert → Falcosidekick → Kubernetes Event
                                    ↓
                            Event-triggered action:
                            - Isolate Pod (NetworkPolicy)
                            - Kill Pod
                            - Scale to 0
                            - Create incident ticket

Best Practices

1. Start with default rules and tune for false positives before adding custom rules
2. Use eBPF driver on kernels 5.8+ for better performance and no kernel module dependency
3. Set resource limits — Falco can be CPU-intensive during high-syscall workloads
4. Alert on CRITICAL and WARNING — use NOTICE for informational monitoring
5. Integrate with SIEM — send alerts to your security information and event management system
6. Combine with admission control — use Falco for runtime and Gatekeeper/Kyverno for admission