Falco 入门实验：Linux／Kubernetes 部署、规则触发与告警查看-未完纪

Falco 从运行时事件中匹配规则，把可疑行为变成包含进程、用户、文件和容器上下文的告警。要弄清它是否接通了采集与输出链路，可以从隔离的 Ubuntu 虚拟机开始，也可以使用专门的 Kubernetes 测试集群。本文合并 Falco 官方的 Linux 快速入门、Kubernetes 快速入门和告警转发指南，核查日期为 2026-10-05。

维护及发布方为 Falco 项目，原页未单列可确认的个人作者。以下输出含义来自原文示例，不是本次部署记录。本次没有安装软件、访问集群、读取密码文件或执行清理命令。

原创示意图：Falco 的事件、规则与告警输出链路；未完纪编辑整理，非运行截图。

先明确实验环境与版本

Linux 原教程以 Ubuntu 24.04 虚拟机为基础，列出 VirtualBox/Vagrant 与 Apple Silicon 上的 Lima。原作者表示在这两种环境中做过验证，未验证其他云或虚拟化平台；这不代表本稿重新验证过。Kubernetes 方案需要可管理的 x86_64 或 ARM64 Linux 节点，以及已经正确配置的 kubectl 和 Helm。原文明确说 Windows/macOS 的 Docker Desktop 不是这套 Kubernetes 演练的适用环境。

本次读取的 Falco 站点导航为 v0.45，但这三篇教程的最后修改日期分别为 2024-09-18、2025-05-16、2025-07-12。正文中的包版本、Chart、默认规则、镜像和命令必须按实际选定版本核对。未固定版本的快速入门命令会随仓库变化，不能当作可重复的生产部署规范。

演练会安装拥有节点可观测能力的组件、修改软件源，故应使用不含生产凭证、个人文件或真实业务数据的专用环境。读取 /etc/shadow 是故意触发敏感文件规则，不是一般健康检查；只可在自己的可丢弃实验虚拟机或容器内使用，且应避免把其内容打印到日志。

路线一：在 Ubuntu 虚拟机安装

准备 VirtualBox 或 Lima

安装适合本机的 VirtualBox 与 Vagrant 后，在专用实验目录内按原文建立 Ubuntu 24.04：

vagrant init bento/ubuntu-24.04
vagrant up
vagrant ssh

原文说明默认登录密码是 vagrant。这是公开的实验凭据，不能用于暴露给非信任网络的长期主机。

Apple Silicon 方案先按 Homebrew 官方指引安装 Homebrew，再安装 Lima，并进入虚拟机：

brew install lima
limactl start --name=falco-quickstart template://ubuntu-lts
limactl shell falco-quickstart

版本注：原文把这个 Lima 模板描述为 Ubuntu 24.04，但 ubuntu-lts 是会变化的别名。若需要复现，应检查模板当前指向并固定实际镜像，不能仅凭别名认定发行版版本。

配置软件源并安装 Falco

进入实验 Ubuntu 后，原文先添加仓库签名密钥与 APT 源。以下管道将下载的公钥交给 GPG，不是把下载脚本直接交给 shell；它仍然改变软件信任边界，需要核实官方地址与密钥指纹。

curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

sudo bash -c 'cat << EOF > /etc/apt/sources.list.d/falcosecurity.list
deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main
EOF'

sudo apt-get update -y
sudo apt-get install -y dialog
sudo apt-get install -y falco

安装界面中选择 Modern eBPF 驱动；随后原文选择允许自动更新规则。自动更新方便入门，也意味着相同触发动作日后可能匹配不同规则。需要可重现或审计的环境应记录 Falco、内核与规则集版本，并设计规则更新流程。

通过 systemd 查看服务：

sudo systemctl status falco-modern-bpf.service

原文展示的是 active (running) 状态、/usr/bin/falco -o engine.kind=modern_ebpf 进程，以及加载 /etc/falco/falco.yaml、默认与本地规则文件、开启 syscall 事件源和 modern BPF probe 的日志。示例还出现监听 0.0.0.0:8765 的健康服务；实际部署应核对监听地址和防火墙，不能因为它叫健康检查就直接向公网开放。原文的内存、CPU、时间戳和内核版本仅是一次示例，不是性能承诺。

触发并检查日志

原文使用下列动作触发敏感文件读取规则；输出丢弃到 /dev/null，但实际读取仍发生：

sudo cat /etc/shadow > /dev/null

通过日志查看告警：

sudo journalctl _COMM=falco -p warning
sudo grep Sensitive /var/log/syslog

原文期望看到 Sensitive file opened for reading by non-trusted program，字段包括 file=/etc/shadow、evt_type=openat、user=root、process=cat、父进程、命令行与 container_id=host。journal 与 syslog 是两种查看途径，具体文件是否存在取决于日志服务配置。仅执行命令无报错不代表 Falco 成功检测；应核对实际规则是否启用、事件源、日志输出以及是否丢失系统调用事件。

路线二：在 Kubernetes 测试集群部署

先确认当前 kubectl context 指向获准操作的实验集群。以下保留原文 Chart 部署形式；部署前应固定经核实的 Chart 版本和镜像摘要。原文的 --replace 影响 Helm 已删除 release 的复用语义，并不是允许覆盖任意现有安装的通用开关。

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install --replace falco --namespace falco --create-namespace \
  --set tty=true falcosecurity/falco
kubectl get pods -n falco
kubectl wait pods --for=condition=Ready --all -n falco

等待所有相关 Pod 就绪后再做触发。原文不指定超时，实际自动化宜按部署规模给出明确超时并检查失败原因。Falco 自带规则集，以下建立独立测试命名空间以免误用当前命名空间中的同名业务 Deployment；这是相对原文新增的隔离措施。

kubectl create namespace falco-lab
kubectl -n falco-lab create deployment nginx --image=nginx
kubectl -n falco-lab rollout status deployment/nginx

nginx 未固定标签，保留了原文的入门用法；正式复现应换成审查过的固定摘要。命名空间隔离本身不构成完整安全边界，测试 Pod 也不应挂载生产卷或注入生产 Secret。

原文通过子命令查询 Pod 名，再在其中读取敏感文件。这里改用 Deployment 目标，避免多个 Pod 名被 shell 展开成歧义参数，并去掉交互终端；增加重定向以防文件内容进入终端：

kubectl -n falco-lab exec deployment/nginx -- cat /etc/shadow > /dev/null
kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning

这仍然是敏感文件读取，仅用于上述隔离容器。检测该动作的是与 nginx Pod 同节点的 Falco 实例。原文告警示例包含敏感文件路径、进程和用户信息，以及容器镜像、标签、容器名、Kubernetes 命名空间和 Pod 名。查看多实例日志时应确认覆盖了目标节点，且日志采样、保留窗口和标签选择器没有让目标事件漏掉。

编写与加载自定义规则

接下来匹配“在主机或容器内打开 /etc 下的普通文件以写入”。将以下内容保存为 falco_custom_rules_cm.yaml，它是 Helm values 文件，虽然原文文件名含有 cm，内容并不是可直接 kubectl apply 的 ConfigMap 对象。

customRules:
  custom-rules.yaml: |-
    - rule: Write below etc
      desc: An attempt to write to /etc directory
      condition: >
        (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0)
        and fd.name startswith /etc/
      output: "File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty"
      priority: WARNING
      tags: [filesystem, mitre_persistence]

与原文的差异：原条件是 fd.name startswith /etc，也可能匹配 /etc-example 这样的前缀。这里改成 /etc/，表达子路径边界；它仍依赖事件字段所提供的路径形式，不是完整的路径规范化或文件完整性保证。open/openat/openat2、写入打开标记、普通文件类型和有效文件描述符共同约束事件。检测“以写入方式打开”不等于证明文件内容确实发生改变。

helm upgrade --namespace falco falco falcosecurity/falco \
  --set tty=true -f falco_custom_rules_cm.yaml
kubectl wait pods --for=condition=Ready --all -n falco
kubectl -n falco-lab exec deployment/nginx -- touch /etc/test_file_for_falco_rule
kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning

touch 会创建或更新时间戳，因而只能对预先确认不存在且可丢弃的实验文件操作。原文期望看到 File below /etc opened for writing 和 file=/etc/test_file_for_falco_rule，并带有 process=touch 与容器上下文。如果文件已存在、工具只更新元数据而没有按规则指定方式打开文件，触发路径可能不同；应根据实际 syscall 和规则版本检查，不能把一次未告警当作 Falco 无效。

把日志变成可查看、可转发的事件

Falcosidekick 是 Falco HTTP 输出的集中转发器。它接收 JSON 告警，转交聊天平台、告警系统、日志服务、对象存储或消息系统，也能增加自定义字段、按优先级筛选并暴露 Prometheus 指标。配置可以来自 YAML 或环境变量。Falcosidekick UI 提供事件查看与统计，但集中保存与响应一般仍需要明确的外部接收方。

在当前 Helm release 中加入 UI

helm upgrade --namespace falco falco falcosecurity/falco \
  -f falco_custom_rules_cm.yaml \
  --set tty=true \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true
kubectl -n falco get svc
kubectl -n falco port-forward svc/falco-falcosidekick-ui 2802:2802

原文服务示例为 falco-falcosidekick 的 2801/TCP 和 falco-falcosidekick-ui 的 2802/TCP。浏览器访问 http://localhost:2802，默认账号密码为 admin/admin。仅限本机转发的实验验证也应尽快修改默认凭据；不要将 UI 通过公网 Ingress 或 --address 0.0.0.0 直接暴露。

进入 Events，再重复实验容器中的规则触发动作，核对 UI 中是否出现对应事件。这里没有展示或伪造任何现场截图。转发页另有 kubectl port-forward svc falco-falcosidekick-ui … 的不规范写法，本文统一使用资源类型与名称合并的 svc/falco-falcosidekick-ui。

转发到 Slack

原文通过 Helm 命令行设置 falcosidekick.config.slack.webhookurl，并把 minimumpriority 设为 notice。Webhook 是秘密，直接放在 --set 中可能进入 shell 历史、进程参数、CI 日志及 Helm release 值记录。下列 YAML 只说明对应配置键，示意 URL 必须由自己的安全配置机制提供，不能当作有效地址：

falcosidekick:
  enabled: true
  webui:
    enabled: false
  config:
    slack:
      webhookurl: "YOUR_WEBHOOK_URL_HERE"
      minimumpriority: notice

不要把替换后的文件提交到源码仓库。生产应按选定 Chart 的实际接口采用 Secret 引用或受控秘密注入，并审查 Helm 状态中是否仍保存明文；单纯从命令行改成 values 文件并不能消除泄露风险。升级时持续合并当前自定义规则和所需值，避免误以为原文一条新的 helm upgrade 会自动保留全部设置。明确关闭 UI 的 webui.enabled: false 也是相对原示例补充的意图表达。

接收方配置正确且事件满足优先级过滤后，Slack 才应收到告警。告警字段可能包含命令行、用户、路径、镜像和 Kubernetes 名称；应按接收方权限、数据保留和脱敏要求审查，不能默认转发所有运行时信息。

Falcosidekick 的其他输出与部署方式

截至本次读取，官方转发页列出的输出按用途如下。它们是能力索引，不意味着每个服务已连接或其默认配置适合生产；具体选项应查阅对应项目文档。

用途	原文列出的输出
聊天	Slack、Rocketchat、Mattermost、Teams、Webex、Discord、Google Chat、Zoho Cliq、Telegram
指标／可观测性	Datadog、InfluxDB、StatsD、DogStatsD、Prometheus、Wavefront、Spyderbat、TimescaleDB、Dynatrace、OTEL Metrics；StatsD/DogStatsD用于转发器监控，Prometheus及OTEL Metrics也可覆盖事件。
告警	AlertManager、Opsgenie、PagerDuty、Grafana OnCall
日志	Elasticsearch、Loki、AWS CloudWatchLogs、Grafana、Syslog、Zincsearch、OpenObserve、SumoLogic、Quickwit、Datadog Logs
对象存储	AWS S3、GCP Storage、Yandex S3 Storage
函数／无服务器	AWS Lambda、GCP Cloud Run、GCP Cloud Functions、Fission、KNative（CloudEvents）、Kubeless、OpenFaaS、Tekton
消息／流	NATS、STAN、AWS SQS、AWS SNS、AWS Kinesis、GCP PubSub、Apache Kafka、Kafka REST Proxy、RabbitMQ、Azure Event Hubs、Yandex Data Streams、MQTT、Gotify
其他	SMTP、Redis、Webhook、Node-RED、WebUI、AWS Security Lake、n8n、OTEL Traces、Falco Talon、Policy Report

若新建 Helm release，原文在 helm install falco falcosecurity/falco -n falco --create-namespace 后增加 --set falcosidekick.enabled=true --set tty=true 即启用转发器；增加 --set falcosidekick.webui.enabled=true 同时启用 UI。已有本文前面建立的 release 时使用 upgrade，不能再直接 install 同名 release。

Docker 方式

转发页原始 Docker 示例使用 falcosecurity/falcosidekick:2.27.0、映射 2801 端口，并通过 SLACK_WEBHOOKURL 环境变量传入配置。下例保留历史版本供解释，改为仅绑定回环地址，并从已设置的环境变量传值：

docker run -d -p 127.0.0.1:2801:2801 \
  -e SLACK_WEBHOOKURL \
  falcosecurity/falcosidekick:2.27.0

这个版本是原教程示例，未在本次核实为推荐版本。回环绑定会限制远端 Falco 直接连接，应按实际网络设计调整；环境变量仍可能通过容器检查接口暴露给有管理权限的人。还需配置 Falco 的 HTTP 输出目标，启动转发器容器本身不会自动接收所有主机告警。

主机二进制与 systemd

原文先建立配置目录，下载匹配版本与架构的压缩包，并解压到系统目录。下列仅保留其下载示意；执行前应按发布方提供的机制验证完整性和来源，再以最小必要权限安装：

sudo mkdir -p /etc/falcosidekick
wget https://github.com/falcosecurity/falcosidekick/releases/download/2.27.0/falcosidekick_2.27.0_linux_amd64.tar.gz
sudo tar -C /usr/local/bin/ -xzf falcosidekick_2.27.0_linux_amd64.tar.gz

这组命令会联网并写入系统目录，架构为 linux_amd64，不能直接用于 ARM64。按项目的示例配置创建 /etc/falcosidekick/config.yaml 后，原文建议建立 /etc/systemd/system/falcosidekick.service。

订正说明：原文 unit 末尾误含 EOF，还没有 [Install] 段，却随后调用 enable。下面移除该多余行，补上安装段。它是最小语法整理，未作为生产服务进行加固或实测：

[Unit]
Description=Falcosidekick
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
ExecStart=/usr/local/bin/falcosidekick -c /etc/falcosidekick/config.yaml

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable falcosidekick
sudo systemctl start falcosidekick

daemon-reload 和 sudo 是本文补充。该最小 unit 没有指定 User，会按系统服务默认身份运行；生产应建立专用低权限账号、配置文件最小读权限与必要服务沙箱。StartLimitIntervalSec=0 配合一秒重启还可能形成无止境重试，应按运维策略设置限制。更改身份前必须确认程序所需目录、配置和证书的访问权限。

清理与验收边界

Kubernetes 原文使用 helm -n falco uninstall falco 卸载 release；它会终止该部署提供的监测，且不等于自动删除所有测试业务对象。本文新增的 nginx 位于独立 falco-lab 命名空间，确认其中只有本次实验资源后，再按集群流程清理。不要把未知命名空间当作可丢弃目录。

Linux 原文使用 limactl delete falco-quickstart --force 或在对应 Vagrantfile 目录执行 vagrant destroy 销毁虚拟机。它们会丢弃虚拟机内数据，必须核对实例名称及需保留内容；本文仅说明原教程清理入口，未执行这些破坏性示例。

完整验收应分别核对驱动和规则加载、目标事件命中、日志接收、HTTP 转发、UI/外部接收方显示与必要的优先级过滤。某一步成功不等于整个告警链路成功。本稿只做静态审查，未进行性能测试或端到端部署验证。