第六篇：《运行时安全：Falco 入侵检测与异常行为监控》

镜像扫描和 CIS 加固解决了“配置对不对”的问题，但它们无法回答一个更关键的问题：运行中的容器正在做什么？ 一个经过安全扫描、符合 CIS 标准的镜像，其运行时行为仍然可能是恶意的——攻击者可能利用漏洞在容器内执行反向 Shell，也可能通过供应链攻击植入后门。运行时安全（Runtime Security） 正是针对这一空白的解决方案。Falco 是 CNCF 毕业的云原生运行时安全工具，通过监控 Linux 内核的系统调用，将容器内的每一个行为与可配置的安全规则进行比对，实时检测异常活动。本文从 Falco 的架构与工作原理讲起，深入讲解 Falco 在 Kubernetes 中的部署（DaemonSet + Helm）、核心检测规则，并通过容器逃逸检测的完整实战，帮你构建云原生环境的主动防御能力。

一、Falco 的架构与工作原理
Falco 由 Sysdig 开源，是 CNCF 毕业项目。其核心能力来自对 Linux 内核系统调用的深度监控。

1.1 内核事件捕获机制
Falco 主要通过三种方式捕获内核事件：

在 Kubernetes 环境中，eBPF 模式是最推荐的部署方式——它不需要编译内核模块，对内核版本要求较低（4.14+），且性能开销可控。

1.2 Falco 的核心组件

Falco 不提供 Kubernetes 原生的 CRD，其策略通过 Helm Chart 的 ConfigMap 进行管理。当执行 helm upgrade 更新自定义策略时，新规则会被部署为 falco-rules ConfigMap。

Falco 的核心库 libsinsp 和插件生态构成了其运行时安全能力的基础。

二、在 Kubernetes 中部署 Falco
2.1 使用 Helm 安装（推荐）

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

# 安装 Falco
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace

部署后，Falco 会以 DaemonSet 的形式在每个节点上运行一个 Pod。每个 Falco Pod 监控其所在节点的所有容器行为。

验证安装：

kubectl get pods -n falco
# falco-xxxxx 应处于 Running 状态

2.2 启用 eBPF 模式（推荐）
在 Kubernetes 环境中，建议启用 eBPF 模式以获得更好的兼容性和性能：

helm upgrade falco falcosecurity/falco -n falco \
  --set ebpf.enabled=true \
  --set ebpf.hostNetwork=true \
  --set driver.kind=ebpf

2.3 检查 Falco 运行状态

# 查看 Falco Pod 日志
kubectl logs -n falco daemonset/falco

# 检查 Falco 规则加载情况
kubectl logs -n falco daemonset/falco | grep "Rules loaded"

三、Falco 规则体系
Falco 的规则采用 YAML 语法定义，由三个核心元素构成：

3.1 规则的基本结构

- rule: <规则名称>
  desc: <规则描述>
  condition: <触发条件的表达式>
  output: <告警输出内容>
  priority: <优先级: EMERGENCY|ALERT|CRITICAL|ERROR|WARNING|NOTICE|INFO|DEBUG>

tags: [<标签列表>]
3.2 默认规则集
Falco 内置了一套丰富的默认规则，覆盖常见的异常行为：

容器内执行 shell（Terminal shell in container）

敏感文件读取（如 /etc/shadow）

特权操作（如 nsenter 或 unshare 执行）

出站网络连接

修改 release_agent 文件（容器逃逸检测）

3.3 编写自定义规则
以下示例检测容器内尝试访问宿主机命名空间的行为，这是容器逃逸的典型前兆：

# custom_rules.yaml
- rule: Detect Host Namespace Access
  desc: Detect process inside container trying to access host namespaces
  condition: >
    container.id != host and
    (evt.type = openat or evt.type = open) and
    fd.name in ( "/proc/1/ns/pid", "/proc/1/ns/net", "/proc/1/ns/mnt" ) and
    proc.name != "falco"
  output: >
    Container attempted to access host namespace
    (user=%user.name command=%proc.cmdline container=%container.name
    file=%fd.name)
  priority: CRITICAL
  tags: [container, escape]

规则解读：

container.id != host：排除宿主机自身进程。

evt.type = openat：监控 openat 系统调用。

fd.name in (…)：目标文件是宿主机的命名空间文件。

触发时输出详细上下文信息，便于溯源。

3.4 在 Helm 中加载自定义规则
将自定义规则保存为文件后，通过 Helm 注入：

helm upgrade falco falcosecurity/falco -n falco \
  --set-file customRules.custom-rules.yaml=./custom_rules.yaml

四、告警响应与自动化
4.1 Falcosidekick：告警转发网关
Falco 的告警可以通过 Falcosidekick 转发到多种目的地：Slack、Teams、Discord、Webhook、Kafka、AWS S3 等。

部署 Falcosidekick：

# 随 Falco 一起安装
helm upgrade falco falcosecurity/falco -n falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/xxx"

4.2 自动响应（Response Engine）
结合 Falco 与 Kubernetes API，可以实现自动响应——检测到恶意行为后自动终止 Pod、添加 NetworkPolicy 或触发审计流程。

典型链路：

Falco 检测到异常行为 → 发送告警到 Falcosidekick。

Falcosidekick 触发 Webhook 到 Kubernetes API。

Kubernetes 执行响应动作（如删除 Pod、打标签隔离）。

五、实战：容器逃逸检测与告警
5.1 模拟容器逃逸行为
在一个测试 Pod 中尝试访问宿主机的 release_agent 文件：

# 创建测试 Pod
kubectl run test-pod --image=alpine --restart=Never -- sh -c "cat /proc/1/ns/pid"

5.2 观察 Falco 告警
查看 Falco Pod 日志：

kubectl logs -n falco daemonset/falco | grep "Detect release_agent"

预期输出类似：

text
CRITICAL: Detect release_agent File Container Escapes (user=root command=cat /proc/1/ns/pid container=test-pod file=/proc/1/ns/pid)
5.3 配置 Slack 告警
通过 Falcosidekick 将告警实时发送到 Slack，实现“检测 → 告警 → 响应”的完整闭环。

六、Falco 与其他运行时安全工具的对比

Falco 的优势在于其 CNCF 毕业项目的成熟度 和 丰富的规则生态，是云原生运行时安全的事实标准。

七、小结
Falco 是 CNCF 毕业的云原生运行时安全工具，通过监控 Linux 内核系统调用检测异常行为。

部署方式：以 DaemonSet 运行在每个节点，推荐使用 eBPF 模式。

规则体系：YAML 语法定义检测条件，支持自定义规则和宏复用。

告警响应：Falcosidekick 将告警转发到 Slack、Webhook 等目的地。

容器逃逸检测：监控 release_agent 文件访问、宿主机命名空间访问等关键行为。