Falco 安装与使用

验证：未记录
适用版本
未记录
验证范围
尚未登记验证记录。
本文缩写（英文全称与中文含义）
缩写 英文全称／名称 中文含义
BPF Berkeley Packet Filter 伯克利包过滤器技术
BTF BPF Type Format BPF 类型格式
CPU Central Processing Unit 中央处理器
eBPF extended Berkeley Packet Filter 扩展 BPF，用于内核可编程观测等场景
ID Identifier 标识符
JSON JavaScript Object Notation 一种结构化数据格式
PVC Persistent Volume Claim 持久卷申领
RBAC Role-Based Access Control 基于角色的访问控制
SIEM Security Information and Event Management 安全信息与事件管理
TLS Transport Layer Security 传输层安全协议

Falco 是什么#

Falco 用于运行时威胁检测，可通过 Linux 系统调用观察容器和节点上的行为，在匹配规则时输出告警。本文使用 Helm 部署 DaemonSet，并通过一条自定义文件操作规则验证告警链路。

Falco 默认负责检测和告警，不会自动阻止系统调用或终止容器。它与 Kyverno 可以配合使用：Kyverno 管理资源准入，Falco 观察资源运行后的行为。

安装准备#

  • 准备 Linux 节点的 Kubernetes 测试集群，以及已配置的 kubectl 和 Helm。
  • 确保有部署 DaemonSet、RBAC 和访问宿主机资源所需的权限；集群的 Pod Security 或其他准入策略必须允许 Falco 所需的安全上下文和挂载。
  • 本文选择 modern_ebpf 驱动。节点内核需要 BTF 和 BPF ring buffer 等特性，通常 Linux 5.8 及以上具备，但应按实际内核特性判断。
  • macOS 可以作为运行 Helm 和 kubectl 的客户端，Falco 本身运行在 Linux 节点上。官方快速入门不适用于 Windows/macOS 的 Docker Desktop 集群。

驱动要求参考内核事件与驱动文档，测试环境要求参考官方 Kubernetes 入门指南。不允许宿主机访问的托管运行环境需要先确认平台支持情况。

kubectl config current-context
kubectl get nodes -o wide
helm version

如需检查 BTF，在实际 Linux 节点上执行以下命令；该检查只验证 BTF 文件存在，不代表所有 eBPF 特性和权限都已满足：

uname -r
test -r /sys/kernel/btf/vmlinux && echo "BTF available"

使用 Helm 安装#

先查询 Chart 并固定版本，检查其应用版本和默认配置。部署方式见官方 Helm 文档。

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm search repo falcosecurity/falco --versions

# 替换为选定且适合当前集群的 Chart 版本。
export FALCO_CHART_VERSION='<选定的 Chart 版本>'
helm show chart falcosecurity/falco --version "$FALCO_CHART_VERSION"
helm show values falcosecurity/falco --version "$FALCO_CHART_VERSION" > falco-default-values.yaml

创建 falco-values.yaml：

driver:
  kind: modern_ebpf
tty: true
falco:
  json_output: true
  stdout_output:
    enabled: true

这里的 driver.kind 是 Helm Chart 参数，由 Chart 生成 Falco 配置；不要将它与 Falco 原生配置的 engine.kind 混用。参数结构应与所选版本的 values 对照，亦可查阅官方 Chart 配置。

helm upgrade --install falco falcosecurity/falco --namespace falco --create-namespace --version "$FALCO_CHART_VERSION" -f falco-values.yaml --wait --timeout 5m

kubectl -n falco get daemonsets,pods -o wide
kubectl -n falco rollout status daemonset/falco --timeout=180s
kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco --tail=100 --prefix=true

确认 DaemonSet 的 DESIRED、CURRENT、READY 数量符合预期，并检查每个需要监控的节点都运行了 Falco。污点、节点选择器或不支持的节点环境都可能造成监控缺口。

示例：检测容器写入指定测试文件#

1. 添加自定义规则#

将以下 customRules 追加到前面同一个 falco-values.yaml 的顶层，保留已有的 driver、tty 和 falco 配置。文件是 Helm values，不应通过 kubectl apply 应用。

customRules:
  demo-rules.yaml: |-
    - rule: Demo container writes marker file
      desc: Detect a container opening the demo marker for writing
      condition: >
        evt.type in (open, openat, openat2)
        and evt.is_open_write=true
        and fd.typechar='f'
        and fd.num>=0
        and container.id != host
        and fd.name=/tmp/falco-demo-marker
      output: >
        Demo marker opened for writing
        (file=%fd.name command=%proc.cmdline container_id=%container.id)
      priority: WARNING
      tags: [demo, filesystem]

规则检查容器内特定路径的成功写入打开操作，使用独立规则名，便于从其他告警中识别。它不依赖 Kubernetes 元数据补全，也不需要读取敏感文件。规则字段含义可参考Falco 规则基础。

更新安装并等待完成：

helm upgrade --install falco falcosecurity/falco --namespace falco --create-namespace --version "$FALCO_CHART_VERSION" -f falco-values.yaml --wait --timeout 5m

kubectl -n falco rollout status daemonset/falco --timeout=180s
kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco --tail=100 --prefix=true

先确认没有规则加载错误，再触发测试。若所选 Chart 未自动重载规则，可执行 kubectl -n falco rollout restart daemonset/falco，并再次等待 rollout 完成。

2. 创建测试容器并触发事件#

kubectl create namespace falco-demo
kubectl -n falco-demo run falco-demo --image=busybox:1.37.0 --restart=Never --command -- sleep 3600
kubectl -n falco-demo wait --for=condition=Ready pod/falco-demo --timeout=120s
kubectl -n falco-demo get pod falco-demo -o wide

kubectl -n falco-demo exec falco-demo -- sh -c 'echo falco-demo > /tmp/falco-demo-marker'

确认测试 Pod 所在节点有就绪的 Falco Pod。写入命令正常完成是预期行为，Falco 只生成告警。

3. 查看告警#

kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco --since=5m --tail=-1 --prefix=true

在日志中寻找 Demo container writes marker file。启用 JSON 输出后，告警通常包含 rule、priority、output 和 output_fields；其中应能看到 /tmp/falco-demo-marker。使用标签选择器读取各 Falco Pod，避免只查看了其他节点的日志。

需要重复验证时，再执行一次写入命令即可。实际告警可能同时包含默认规则的结果。

可选：通过 Falcosidekick 转发告警#

Falcosidekick 用于将 Falco 告警转发到外部日志或通知系统。只启用组件不会自动配置任何外部接收端，需根据目标系统设置输出参数，参考官方转发文档。

可在现有 falco-values.yaml 顶层追加：

falcosidekick:
  enabled: true

然后再次执行前面的 Helm 更新命令。Chart 会配置 Falco 到 Falcosidekick 的连接。通过以下命令检查转发组件：

kubectl -n falco get deployments,services
kubectl -n falco logs deployment/falco-falcosidekick --tail=100

Webhook、令牌等凭据应通过所选 Chart 支持的 Secret 配置提供，不应写入文档或提交到 Git。接入完成后再次触发测试文件规则，确认接收端收到事件。

日常使用与排错#

kubectl -n falco get pods -o wide
kubectl -n falco describe daemonset falco
kubectl -n falco get events --sort-by=.lastTimestamp
现象 检查方向
Pod Pending 节点污点、调度约束、资源不足及准入策略
Init 容器失败 镜像或规则制品下载是否可达，查看对应 Init 容器日志
eBPF 加载失败 实际节点是否具备 BTF、ring buffer 和所需权限；按平台调整驱动配置
自定义规则未生效 values 缩进、规则语法、启动日志，以及 ConfigMap 更新是否已加载
测试没有告警 测试 Pod 所在节点是否被覆盖、写入是否成功、日志时间范围是否正确
Kubernetes 字段为 <NA> 检查容器运行时和元数据插件配置；元数据缺失不一定表示没有采集到系统调用
告警丢失或事件丢弃 查看 dropped syscall 相关日志/指标，评估节点负载、Falco CPU 和缓冲区配置

针对某个反复重启的 Pod，可执行 kubectl -n falco logs <Pod 名称> -c falco --previous 查看上一次运行日志。驱动和启动问题可进一步查阅官方排错文档。

生产环境应持续观察事件丢弃情况，并基于实际工作负载收敛规则和例外条件，避免直接关闭整类检测。本文只演示系统调用事件，Kubernetes Audit 事件需要单独配置事件源和对应插件。

企业 Hands-on：运行时告警接入值班闭环#

前面的测试文件规则只验证引擎；企业演练采用 真实业务基线。Falco 只检测，不保证阻断；策略阻断由准入、最小权限和网络控制承担。先确认节点内核/驱动、特权权限及 Autopilot/Fargate 等平台支持边界。

平台先基于一周以上正常流量审阅默认规则噪声，建立每条规则的负责人、严重度、例外依据和有效期。输出 JSON，经 Falcosidekick 的企业 TLS 接收端接入 SIEM/值班系统，凭据由 Secret 提供；至少覆盖 cluster、namespace、Pod、container、rule、time，避免采集命令参数中的敏感凭据。

在真实预生产 workload 使用的服务账户/容器安全上下文上，给专门的验证 Job加 security-exercise: approved 标签；Job 只访问自身 /tmp，不读取系统或业务秘密。追加下方规则到原 Helm values 的 customRules，保留原生产规则：

customRules:
  enterprise-exercise.yaml: |-
    - rule: Approved runtime exercise executes shell
      desc: Validate SIEM delivery using an explicitly labelled exercise workload
      condition: >
        spawned_process and container and
        k8s.ns.name = orders and
        k8s.pod.label.security-exercise = approved and
        proc.name in (sh, bash)
      output: >
        Approved security exercise
        (rule=%evt.type ns=%k8s.ns.name pod=%k8s.pod.name
        container=%container.id process=%proc.name)
      priority: NOTICE
      tags: [enterprise_exercise]

先按所选 Falco 版本验证 Kubernetes metadata 字段/富化组件可用；没有元数据时该规则可能不匹配，不能假装“没告警所以安全”。这是告警交付验证规则，并不替代真实异常 shell、敏感文件、意外网络连接的生产检测策略。

helm upgrade --install falco falcosecurity/falco -n falco --version "$FALCO_CHART_VERSION" -f falco-values.yaml --wait --timeout 10m
kubectl -n falco rollout status daemonset/falco --timeout=5m
kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco --since=5m --prefix=true

企业验证 Job 使用批准的固定 digest 诊断镜像，命令只运行 sh -c 'printf runtime-exercise'，设置 runAsNonRoot、drop ALL、只读根目录和资源上限。在各节点池各执行一次：核对事件到达 SIEM、去重关联、通知路由、值班确认和工单关闭；保存总耗时与事件 ID。

故障演练 必须确认
Agent 滚动升级 节点池无长期覆盖缺口，驱动/规则加载正确，丢事件有告警
转发端短暂不可用 重试、队列/丢弃指标可见；Falcosidekick 不应被假设为无限持久消息队列
节点压力上升 syscall drop 指标、CPU/内存和业务 p95 可接受，必要时调整资源和规则
告警接收身份越权 只能写指定租户/索引，不能读全企业日志或控制云资源

对不可容忍的告警丢失，采用已验证的持久消息链路并测算容量。默认不要自动杀容器；自动响应必须精确匹配、可审计、限速且先在 staging 演练，以免误报中断订单业务。

验证完成移除 exercise Job/规则，保留生产检测与收敛后的例外。恢复时回到上一个已验证 Chart、完整 values 和规则集，检查驱动兼容，再重放验证事件。

原实验的升级与清理#

将 Chart 版本、values 和自定义规则一起保存。升级前检查 Falco、Chart、规则集和插件的兼容要求；更新 FALCO_CHART_VERSION 后使用完整 values 执行前面的 Helm 更新命令，完成后重新触发测试规则。

清理测试 Pod 和命名空间：

kubectl delete namespace falco-demo

如果继续保留 Falco，从 falco-values.yaml 中删除本文的测试规则并重新执行 Helm 更新。仅在不再需要运行时检测时卸载：

helm uninstall falco --namespace falco

卸载后相关节点将不再由该实例检测。若额外启用了带存储的组件，还需单独检查其 PVC 保留策略。

Backward Kyverno
多团队资源计量与成本分摊 Forward

搜索文档

输入关键词，搜索所有文档。

↑ ↓ 选择 · Enter 打开 · Esc 关闭