在 Kubernetes 集群投入生产后，攻击面从代码仓库和镜像仓库延伸到了正在运行的容器内部。仅仅在 CI 阶段做镜像漏洞扫描，无法发现容器启动后发生的异常进程执行、文件篡改或非法网络连接。Falco 是一款专注于运行时安全的开源项目，它直接观测 Linux 系统调用与 Kubernetes 审计事件，能够在威胁发生的瞬间给出告警。本文将围绕 Falco 的部署模式、规则机制以及实战检测场景，说明如何把它落地到真实的集群防护中。
Falco 的架构与 Kubernetes 部署方式
Falco 的核心由内核探针、用户态引擎和规则系统三部分组成。在早期版本中，它依赖内核模块接管系统调用；而现在主流方案是使用 eBPF 程序，避免了频繁编译内核模块带来的运维负担。用户态引擎从探针接收事件流，依据 YAML 格式的规则文件进行匹配，命中后输出到标准输出、文件或外部消息队列。在 Kubernetes 里，最典型的部署形态是 DaemonSet，保证每个工作节点都运行一个 Falco 实例，从而完整覆盖节点上所有 Pod 的运行时行为。
使用 Helm 可以大幅简化安装过程。添加 falcosecurity 仓库后，通过几个参数就能指定驱动类型与输出后端。例如选择 eBPF 驱动并开启向 Kafka 的投递，便于后续集中分析。需要注意的是，由于 Falco 要读取宿主机的内核事件，容器必须以特权模式运行，并挂载 /proc 与 /sys 等目录。如果集群启用了 SELinux 或 AppArmor，还需配置相应策略放行，否则会出现权限拒绝导致事件丢失。
除了节点级 DaemonSet，Falco 还能对接 Kubernetes 审计日志。借助 falco-k8s-audit 组件，API Server 的敏感操作（如 exec 进入容器、创建特权 Pod）也会成为检测数据源。这种双通道采集让 Falco 不仅看得见容器内部，也看得清控制面的异常请求，对多租户集群尤其重要。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: falco
namespace: falco
spec:
selector:
matchLabels:
app: falco
template:
metadata:
labels:
app: falco
spec:
containers:
- name: falco
image: falcosecurity/falco:latest
securityContext:
privileged: true
volumeMounts:
- name: proc
mountPath: /proc
- name: sys
mountPath: /sys
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys
Falco 规则引擎与自定义检测逻辑
Falco 的规则文件由规则（rule）、宏（macro）和列表（list）构成。列表用于枚举值集合，比如常见的敏感文件路径；宏是可复用的条件片段，例如定义一个宏表示“在容器内”；规则则组合这些条件，并声明优先级与输出模板。当事件满足规则条件时，Falco 按模板生成告警消息，其中可引用诸如 %k8s.pod.name、%proc.name 等字段，使运维人员一眼定位到具体负载。
默认规则库已经覆盖了大量场景，例如检测到容器内启动 shell、读取 /etc/shadow、使用 curl 下载远端脚本等。但在实际业务中，误报常常来自合法的运维操作。此时应通过自定义规则做白名单处理。比如内部批处理任务会周期性执行 bash 脚本，就可以在规则条件里排除特定命名空间或镜像名，避免噪声淹没真实威胁。下面示例展示了一条检测容器逃逸尝试的规则片段。
编写规则时要关注性能影响。过于宽泛的条件会让引擎频繁求值，尤其在高密度节点上可能造成事件延迟。建议把高开销的判断放在宏中并尽量使用索引字段。此外，Falco 支持规则热加载，修改文件后无需重启进程即可生效，这为动态调整策略提供了便利。团队可以把规则纳入 Git 仓库管理，通过 CI 校验语法并自动同步到集群。
- list: sensitive_files items: [/etc/shadow, /etc/passwd, /root/.ssh] - macro: in_container condition: (k8s.pod.name != "") - rule: Read Sensitive File in Container desc: 检测容器内读取敏感文件 condition: in_container and open_read and fd.name in sensitive_files output: "敏感文件读取 (pod=%k8s.pod.name, file=%fd.name, proc=%proc.name)" priority: WARNING
实战中的典型威胁检测与响应
第一个常见场景是恶意进程注入。假设攻击者通过应用漏洞在容器内执行了挖矿命令，Falco 可依据“容器内新进程且父进程为 web 服务”的规则立刻告警。配合告警 Webhook，安全系统能自动调用 Kubernetes API 对该 Pod 执行隔离或驱逐。相比人工发现，这种闭环将响应时间从小时级压缩到秒级，显著降低损失。
第二个场景是容器逃逸。当容器内尝试挂载宿主机根目录或调用特权系统调用时，Falco 的默认规则会标记为高危。例如某业务容器误配了 hostPath 挂载 /，被规则命中后，平台团队可迅速排查 Deployment 配置。在审计要求的驱动下，这类事件还能同步到 SIEM 系统，满足合规留存。通过和历史基线对比，还能识别出平时安静、某天突然活跃的服务账户。
第三个场景是数据外泄。Falco 能监控异常的出站网络连接，比如容器向陌生 IP 发起大量请求。结合网络策略，可将嫌疑 Pod 限制到仅允许内部通信。在真实案例中，某电商集群曾因 Falco 告警发现测试环境镜像被误投到生产并外联未知地址，及时阻断避免了凭证泄露。由此可见，运行时安全不是可选项，而是生产集群的必备防线。
{
"rule": "Terminal Shell in Container",
"priority": "NOTICE",
"output": "容器内启动shell (pod=%k8s.pod.name, namespace=%k8s.ns.name, shell=%proc.name)",
"output_fields": ["k8s.pod.name", "k8s.ns.name", "proc.name"]
}
将 Falco 纳入日常安全运营，需要从告警分级、接收通道和处置流程三方面设计。对于 WARNING 以上级别的事件应接入值班系统，而 NOTICE 类可先累积观察。随着规则不断调优，Falco 会从单纯的告警工具演进为集群可信基线的一部分，为云原生环境提供持续的运行时保护。
KubernetesFalco运行时安全修改时间：2026-08-18 11:20:33