/runtime-security

name: runtime-security
description: Detect and respond to in-container threats at the syscall level using Falco (eBPF-based, CNCF, open-source, no license cost). Covers Falco installation on EKS/GKE with eBPF driver, custom rule authoring, alert routing via Falcosidekick, rule debugging, and bridging Falco runtime signals to Kyverno admission enforcement. Use when asked to "detect privilege escalation in containers", "set up runtime threat detection", "write a Falco rule", "route Falco alerts to Slack", or "debug why my Falco rule is not firing".
argument-hint: "[install|rules|alerts|debug|harden] [description or symptom]"
title: "Runtime Security Command"
sidebar_label: "runtime-security"
custom_edit_url: null

Detect and respond to threats inside running containers using Falco.

---

Interactive Wizard (fires when no arguments are provided)

When invoked with no arguments, ask before proceeding:

**Q1 — Mode?**

What do you need?
  1. install  — deploy Falco on Kubernetes (EKS or GKE) with eBPF driver
  2. rules    — write and test a custom Falco rule
  3. alerts   — configure Falcosidekick to route alerts (Slack, webhook, etc.)
  4. debug    — diagnose why a Falco rule is not firing
  5. harden   — map runtime Falco alerts to Kyverno admission policies

Enter 1–5 or mode name:

**Q2 — Context** (after mode selected, one at a time):

• **install**: `Which cloud platform? EKS / GKE / other (specify node OS if known):`
• **rules**: `Describe the behaviour to detect (e.g. "shell spawned in a container", "unexpected outbound connection"):`
• **alerts**: `Which output destination? Slack / webhook / PagerDuty / other:`
• **debug**: `Describe the symptom — which rule is not firing, and what event should trigger it?`
• **harden**: `Which Falco alert or rule output should block re-admission? (paste the alert or rule name):`

Then proceed into the relevant mode below.

---

Mode: install

Deploy Falco on Kubernetes (EKS or GKE) using the eBPF driver via Helm.

Prerequisites:

• Helm 3.x
• `kubectl` access to the target cluster
• Node OS: Amazon Linux 2/2023 (EKS) or Container-Optimized OS (GKE) — both support eBPF

Steps: 1. Add the Falco Helm repository:

   helm repo add falcosecurity https://falcosecurity.github.io/charts
   helm repo update

2. Install Falco with eBPF driver (never kernel module on managed K8s):

   helm install falco falcosecurity/falco \
     --namespace falco \
     --create-namespace \
     -f examples/runtime-security/falco-values.yaml

3. Verify DaemonSet is running on all nodes:

   kubectl rollout status daemonset/falco -n falco
   kubectl get pods -n falco -o wide

4. Confirm Falco is receiving events:

   kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=20

Expected: lines like `Notice A shell was spawned...` (from the default ruleset test events)

EKS-specific note: if using Bottlerocket nodes, set `driver.kind: modern_ebpf` in Helm values — Bottlerocket does not ship kernel headers for the classic eBPF probe.

GKE-specific note: COS nodes require `driver.kind: modern_ebpf`. GKE Autopilot does not support Falco (no DaemonSet scheduling).

Mode: rules

Write and test custom Falco rules.

Steps: 1. Explain the rule structure:

   - rule: Shell spawned in container
     desc: A shell was spawned inside a container — potential interactive intrusion
     condition: >
       spawned_process
       and container
       and shell_procs
       and not container.image.repository in (allowed_shell_images)
     output: >
       Shell spawned in container
       (user=%user.name user_id=%user.uid
        container=%container.name image=%container.image.repository
        shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
     priority: WARNING
     tags: [container, shell, mitre_execution]

2. Key condition fields:

• `spawned_process` — a new process was exec'd
• `container` — event is inside a container (not on the host)
• `proc.name` — process name
• `container.image.repository` — image name without tag
• `fd.net` — network file descriptor (for connection events)

3. Test with falco-event-generator:

   kubectl run event-generator \
     --image=falcosecurity/event-generator \
     --restart=Never \
     --rm -it -- run syscall

Then check logs: `kubectl logs -n falco -l app.kubernetes.io/name=falco | grep WARNING` 4. Load custom rules via Helm values:

   customRules:
     custom-rules.yaml: |-
       - rule: Shell spawned in container
         ...

Mode: alerts

Configure Falcosidekick to route Falco alerts to Slack, webhooks, or other outputs.

Steps: 1. Install Falcosidekick alongside Falco:

   helm upgrade --install falco falcosecurity/falco \
     --namespace falco \
     --create-namespace \
     --set falcosidekick.enabled=true \
     --set falcosidekick.webui.enabled=true \
     -f examples/runtime-security/falcosidekick-values.yaml

2. Configure Slack output in Falcosidekick values:

   falcosidekick:
     config:
       slack:
         webhookurl: "https://hooks.slack.com/services/<token>"
         minimumpriority: warning
         messageformat: >
           Alert: *{{ .Rule }}* (Priority: {{ .Priority }})
           Container: `{{ index .OutputFields "container.name" }}`
           Image: `{{ index .OutputFields "container.image.repository" }}`

3. Verify alerts are routing:

   kubectl port-forward -n falco svc/falco-falcosidekick-ui 2802:2802
   # Open http://localhost:2802 — events appear in the UI

4. Deduplication: set `slack.minimumpriority: warning` to suppress DEBUG/INFO noise

Mode: debug

If you need deeper context on any Falco component, load `references/runtime-security.md`.

Diagnose why a Falco rule is not firing.

Checklist (work through in order): 1. **Is Falco running?**

   kubectl get pods -n falco -o wide