云原生运行时防护IDS应用安全【免费下载链接】falcoCloud Native Runtime Security项目地址https://gitcode.com/gh_mirrors/fa/falco点击查看免费下载Falco Helm Chart 在 v3.0.0 到 v9.0.0 之间经历了多轮重大重构引入 falcoctl 自动化工件管理、移除 gRPC 输出、废弃 Legacy eBPF 探针与 gVisor 引擎、重构 driver 配置结构、更换默认镜像与容器元数据采集方式。本文以 chart/falco/BREAKING-CHANGES.md 为骨架逐版本梳理每一项破坏性变更的来龙去脉、影响范围与迁移命令并结合本仓库的 values.yaml、templates/_helpers.tpl、templates/pod-template.tpl 等源码给出配置级佐证帮助你安全完成从旧版 Chart 到新版 Chart 的升级。版本变更总览下表汇总了当前 ChartChart.yaml 中 version 为9.1.0、appVersion 为0.44.1自 v3.0.0 以来每一处破坏性变更及其影响面方便你在升级前快速定位自己可能受影响的配置项Chart 版本破坏性变更受影响配置迁移方向9.0.0移除 gRPC output 与 gRPC serverfalco.grpc、falco.grpc_output迁移到 HTTP / File / Stdout 输出或 Falcosidekick9.0.0移除 Legacy eBPF probe 与 gVisor 引擎driver.kindebpf、driver.kindgvisor改用driver.kindmodern_ebpf8.0.0废弃 gRPC output 与 gRPC server同上同上启动时仅告警8.0.0废弃 Legacy eBPF probe 与 gVisor 引擎同上同上启动时仅告警7.0.0移除废弃的容器元数据 collectorscollectors.containerd、collectors.cri、collectors.docker改用collectors.containerEngine6.0.0Falco Talon 配置重命名falcotalon、falcotalon.enabled改用falco-talon、responseActions.enabled5.0.0默认镜像切换为 distrolessimage.tag按需覆盖image.tag如0.41.0-debian4.0.0driver 配置重构driver.module、driver.modern-bpf、driver.gvisor改用driver.kmod、driver.modern_ebpf4.0.0移除旧 Kubernetes client 及关联 RBACservice account / cluster role / cluster role binding启用collectors.kubernetes部署 k8s-metacollector4.0.0镜像不再内置插件插件加载方式启用resolveDeps由 falcoctl 安装插件3.0.0引入 falcoctl、移除捆绑 rulesfilesrules_files、falcoctl.*使用 falcoctl 安装/跟随规则工件3.0.0放弃falcosecurity/falco镜像driver.loader.enabled使用falco-no-driver默认镜像 driver-loader9.0.0gRPC 输出与 Legacy eBPF / gVisor 正式移除gRPC output 与 gRPC server 移除自 Falco 0.44.0 起此前 0.43.0 已发出废弃通知gRPC output 与内嵌的 gRPC server 不再受支持。gRPC server 的移除是 gRPC output 移除的直接结果——后者依托前者向客户端推送告警流。如果你在values.yaml中仍配置了falco.grpc或falco.grpc_outputChart 会在渲染阶段直接失败。仓库中的 templates/_helpers.tpl 实现了falco.removedConfigGuard守卫模板将已移除的配置项显式列入黑名单{{- $removedDriverKinds : list ebpf gvisor -}} {{- $removedDriverKeys : list ebpf gvisor -}} {{- $removedFalcoKeys : list grpc grpc_output -}} ... {{- fail (printf The following chart configuration is no longer supported: %s. See BREAKING-CHANGES.md for migration guidance. (join , $found)) -}}也就是说升级到 9.x 后如果旧配置里还留着falco.grpc.*或falco.grpc_output.*helm upgrade会直接报错并提示你查阅 BREAKING-CHANGES.md而不是静默忽略——这是比 8.0.0 时期的启动时告警更强硬的保护。迁移建议改用以下替代输出通道这些通道在 values.yaml 中均有完整配置项HTTP outputfalco.http_output支持 URL、user_agent、CA 证书ca_cert/ca_bundle/ca_path、mTLS 客户端证书mtls、client_cert、client_key、compress_uploads、keep_alive等参数File outputfalco.file_output支持keep_alive、filename注意 Falco 不会对文件做日志轮转收到 SIGUSR1 会关闭并重开文件Stdout outputfalco.stdout_outputenabled: true即可Falcosidekick作为高级集成入口可把告警转发到 Slack、Teams、Webhook 等下游。Chart 中通过falcosidekick.enabled条件依赖引入见 Chart.yaml。Legacy eBPF probe 与 gVisor 引擎移除同样自 Falco 0.44.0 起以下引擎不再受支持Legacy eBPF probedriver.kindebpf官方建议改用Modern eBPF probedriver.kindmodern_ebpf后者具备更好的性能与更广的内核兼容性gVisor enginedriver.kindgvisor官方建议改用其他监控方案。_helpers.tpl中的falco.engineConfiguration也印证了当前 Chart 支持的 driver 类型范围kmod、modern_ebpf、auto外加兼容旧写法的别名module、modern-bpf一旦传入ebpf或gvisor同样会被 removedConfigGuard 拦截。从本仓库的废弃提案 proposals/20251215-legacy-bpf-grpc-output-gvisor-engine-deprecation.md 可以了解废弃的技术动因Legacy eBPF 探针无法利用 CO-RECompile Once, Run Everywhere特性官方必须为每种内核风味维护独立编译的 eBPF 对象维护负担大且旧内核上 verifier 限制苛刻gVisor 引擎无法提供与内核驱动完全等价的事件类型且引入 protobuf 依赖显著增加构建时间。这些内容对评估迁移成本很有参考价值。8.0.0废弃期行为——启动告警而非硬失败自 Falco 0.43.0 起上述两组功能进入废弃期如果配置了falco.grpc.enabledtrue或falco.grpc_output.enabledtrue或使用了driver.kindebpf/driver.kindgvisorFalco 会在启动时输出警告但功能仍然可用。废弃期只持续一个版本0.43.0 → 0.44.0因此如果你仍处于 8.x Chart务必在升级到 9.x 之前完成迁移否则升级将因配置校验失败而中止。7.0.0容器元数据 collectors 统一为 containerEngineChart v4.22 起废弃的三个独立 collectors 选项在 v7.0.0 被正式移除collectors.containerdcollectors.cricollectors.docker请改用collectors.containerEngine。新方案通过统一的容器插件container plugin从各类容器运行时采集元数据并在底层复用同一套引擎配置。当前 values.yaml 中collectors.containerEngine的结构如下collectors: containerEngine: enabled: true pluginRef: ghcr.io/falcosecurity/plugins/plugin/container:0.7.5 labelMaxLen: 100 withSize: false hooks: [create] engines: docker: enabled: true sockets: [/var/run/docker.sock] podman: enabled: true sockets: [/run/podman/podman.sock] containerd: enabled: true sockets: [/run/host-containerd/containerd.sock] cri: enabled: true sockets: [/run/containerd/containerd.sock, /run/crio/crio.sock, ...] lxc: enabled: true libvirt_lxc: enabled: true bpm: enabled: trueengines下同时保留了docker、containerd、cri等子开关用于控制对具体运行时 socket 的监听因此从旧的三个 collectors 迁移到containerEngine时把原来的启用/禁用意图平移到engines.name.enabled即可。底层实现上templates/_helpers.tpl 中的falco.containerPlugin会把容器插件写入falco.plugins与falco.load_plugins并自动把pluginRef追加到 falcoctl 的安装清单中falco.containerPluginVolumes 则负责按引擎 socket 目录生成 hostPath 卷挂载的是 socket 所在目录而非 socket 文件本身避免运行时重启后 pod 持有失效 inode。6.0.0Falco Talon 配置重命名v6.0.0 对values.yaml做了两处不兼容改名falcotalon更名为falco-talonfalcotalon.enabled更名为responseActions.enabled当前 values.yaml 中的对应结构为# -- Enable the response actions using Falco Talon. responseActions: enabled: false # -- It must be used in conjunction with the response_actions.enabled option. falco-talon: {}同时 Chart.yaml 中通过condition: responseActions.enabled条件依赖引入falco-talon子 Chart。升级时只需把旧的falcotalon:键改名为falco-talon:、把falcotalon.enabled改为responseActions.enabled其余子配置结构不变。5.0.0默认镜像切换为 distroless从 v5.0.0 开始Chart 默认使用 Falco 标准容器镜像这是一个不带任何额外工具的 distroless 镜像。此前 Chart 使用包含多种工具的debian镜像以避免升级过程中的破坏新镜像更安全、更轻量但不再内置这些工具。迁移影响如果你依赖镜像中的某些工具——典型场景是program_output特性通过program_output.program调用jq、curl、nc等外部命令见 values.yaml 中的示例配置——需要手动覆盖image.tag以选用其他镜像风味。例如image: tag: 0.41.0-debian即可恢复 Debian 版镜像中的工具集。如果你的告警消费链路不依赖任何外部命令如仅使用 stdout / file / http 输出保持默认 distroless 镜像即可获得更小的攻击面。4.0.0driver 配置重构与 K8s 元数据采集改造Drivers统一 driver 命名与配置分组v4.0.0 依据 Falco 上游 PR 对driver段进行了整体重构目标是统一 Falco 中 driver 的配置方式并按 driver 类型分组配置。具体改名如下旧名称新名称说明module内核模块kmod重命名ebpfLegacy eBPF probeebpf未变后于 8.x/9.x 废弃移除modern-bpfmodern_ebpf重命名gvisordriver.gvisor从独立顶层配置移入driver段当前 values.yaml 中driver段的结构为driver: enabled: true # 可用选项kmod内核模块、modern_ebpfModern eBPF 探针、auto kind: auto sysfsMountPath: /sys/kernel kmod: bufSizePreset: 4 dropFailedExit: false modernEbpf: leastPrivileged: false bufSizePreset: 4 dropFailedExit: false cpusForEachBuffer: 2 disableIterators: false sysfsMount: true loader: enabled: true initContainer: image: repository: falcosecurity/falco-driver-loader ...值得注意的是driver.kindauto这是当前默认值由 driver-loader 在节点上自动探测并选择可用驱动。_helpers.tpl中的falco.engineConfigurationtemplates/_helpers.tpl会把auto展开为同时携带kmod与modern_ebpf两套参数的 engine 配置driverLoader.enabledtemplates/_helpers.tpl则决定是否注入 driver-loader init container。另外driver.modernEbpf.leastPrivileged: true时容器将以BPF、SYS_RESOURCE、PERFMON、SYS_PTRACE四个 capability 运行而非 privileged见 pod-template.tpl 中的falco.securityContext。K8s Collector旧 Kubernetes client 移除改由 k8s-metacollector k8smeta 插件承担Falco 0.37.0 移除了旧版 Kubernetes client。作为替代k8s-metacollector组件与k8smeta插件接管了 Kubernetes 元数据采集。随之Chart 中以下为 Falco 直连 API server 准备的资源被移除service accountcluster rolecluster role binding当collectors.kubernetes.enabledtrue时Chart 会部署 k8s-metacollector 子 Chart条件依赖见 Chart.yaml并自动配置 Falco 加载 k8smeta 插件。默认情况下collectors.kubernetes.enabled为关闭状态values.yaml因为该采集器需要额外的部署成本关闭时 Falco 回退到容器注解获取元数据此时仅有 pod 的 ID、名称、namespace、labels 可用。collectors.kubernetes的关键配置项pluginRefk8smeta 插件的 OCI 引用默认ghcr.io/falcosecurity/plugins/plugin/k8smeta:0.4.2collectorHostname/collectorPortk8smeta 插件连接 k8s-metacollector 的 gRPC 地址与端口端口默认取 k8s-metacollector 服务的broker-grpc端口 45000verbosity插件日志级别trace / debug / info / warning / error / criticalhostProc宿主机 /proc 的挂载前缀默认/hostPlugins镜像不再内置插件启用 resolveDeps 按需安装Falco Docker 镜像不再随镜像发布插件。因此Chart 在相关 values 文件如values-k8saudit.yaml中启用了resolveDeps当 falcoctl 安装 rulesfile 工件时会解析其依赖并顺带安装所需插件。以 values-k8saudit.yaml 为例纯插件部署无 syscall driver场景的配置要点是driver: enabled: false # 仅部署 k8saudit 插件无需 driver collectors: enabled: false # 无 syscall 事件需要元数据富化 controller: kind: deployment # 单实例即可 deployment: replicas: 1 falcoctl: artifact: install: enabled: true # init container 安装工件 follow: enabled: true # sidecar 跟随更新 config: artifact: install: refs: [k8saudit-rules:0.16, k8saudit:0.16] follow: refs: [k8saudit-rules:0.16] falco: load_plugins: [k8saudit, json]注意此处的falcoctl.config.artifact.allowedTypes会由 Chart 自动扩展为包含plugin同时把容器插件 / k8smeta 插件的pluginRef自动追加到 install 的refs中见 templates/_helpers.tpl 与falco.containerPlugin。3.0.0falcoctl 时代开启v3.0.0 是 Chart 历史上最大的一次架构变更新 Chart 部署了新的 K8s 资源并在values.yaml中新增了大量配置变量。从 v2.x 升级的用户需要把旧配置移植到新values.yaml。好消息是Falco 本体由 Chart 安装的版本不引入破坏性变更你可以直接把旧 Falco 配置复制粘贴到新 values 中。Falcoctl自动安装与跟随工件在 v3.0.0 之前rulesfiles 与插件都捆绑在 Falco 镜像中导致无法独立更新——运营者必须手动更新 rulesfiles、自行构建包含新插件的镜像或等待 Falco 新版本发布过程繁琐且易错。v3.0.0 起 Chart 引入falcoctl实现install安装 Falco 生态工件插件、规则文件follow跟随工件更新官方建议仅对 rulesfile 使用保持规则与 falcosecurity 组织的最新发布同步从而在无需重新部署 Falco 的情况下更新检测新漏洞/安全问题的规则。Chart 通过init container安装工件并在 Falco 启动前就绪经 emptyDir 卷共享和sidecar container常驻 Falco 旁检测到更新即下载安装到共享目录两种方式部署 falcoctl规则文件被安装到正确目录后会被 Falco 自动加载且 falcoctl 会在安装前校验工件与运行中 Falco 版本的兼容性。上述两种容器的渲染逻辑分别位于 templates/pod-template.tplsidecar 与 init container 注入以及_helpers.tpl的 falcoctl 相关 define 中共享的 emptyDir 卷plugins-install-dir、rulesfiles-install-dir、artifact-state-dir的定义见 pod-template.tpl。当前 values.yaml 中的 falcoctl 默认配置以当前仓库为准注意默认值与 v3.0.0 文档示例已有差异falcoctl: image: pullPolicy: IfNotPresent registry: docker.io repository: falcosecurity/falcoctl tag: 0.14.2 artifact: install: enabled: true args: [--log-formatjson] follow: enabled: true args: [--log-formatjson] config: indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml artifact: allowedTypes: - rulesfile - plugin install: resolveDeps: true refs: [falco-rules:5] rulesfilesDir: /rulesfiles pluginsDir: /plugins stateDir: /artifactstate follow: refs: [falco-rules:5] every: 168h falcoversions: http://localhost:8765/versions rulesfilesDir: /rulesfiles pluginsDir: /plugins stateDir: /artifactstate关键参数说明indexesfalcoctl 下载并用于定位/下载工件的索引列表allowedTypes允许处理的工件类型白名单解析出的工件类型不在列表中会被拒绝安装install.resolveDeps是否解析工件依赖v4.0.0 起镜像不再内置插件因此默认true插件由 falcoctl 顺带安装install.refs/follow.refs要安装/跟随的工件引用支持名称:版本语法everyfollow 检查更新的周期当前默认168hv3.0.0 文档示例为每 6hfalcoversionsfalcoctl 用于校验工件与运行中 Falco 兼容性的版本端点指向 Falco 内嵌 webserver 的/versions接口webserver 配置见 values.yamllisten_port默认 8765rulesfilesDir/pluginsDir工件落盘目录与 Falco 容器共享stateDirfalcoctl 状态文件目录在 install 与 follow 之间共享以保持一致。falcoctl 配置本身保存在 ConfigMap 中并挂载到容器见 templates/falcoctl-configmap.yaml该 ConfigMap 还会并入 Chart 自动生成的 container 插件与 k8smeta 插件配置。基于部署场景的四种升级路径原文档完整保留无插件、仅升级 Falco 版本helm upgrade falco falcosecurity/falco \ --namespacefalco \ --reuse-values \ --set falcoctl.artifact.install.enabledfalse \ --set falcoctl.artifact.follow.enabledfalse升级既有 release 时 Helm 使用新 Chart 版本由于新增了模板文件且 values schema 有变化显式禁用 falcoctl 即可复用旧配置、仅将 Falco 升级到新版本。无插件、希望自动获取最新 falco-ruleshelm upgrade falco falcosecurity/falco \ --namespacefalcoHelm 先应用新 Chart 的默认 values再用上一 release 的 values 覆盖最终结果是沿用旧配置、运行新版 Falco、falcoctl 安装并自动更新官方规则工件、按follow.every周期检查更新。有插件、仅升级 Falco与场景 1 相同的命令显式禁用 install / follow。有插件、希望用 falcoctl 下载插件的 rulesfiles将 falcoctl 配置写入独立 values 文件如./falcoctl-values.yaml核心内容包括falcoctl.artifact.install.enabledtrue并设置falcoctl.config.artifact.install.refs[k8saudit-rules:0.5]按实际插件名调整然后执行helm upgrade falco falcosecurity/falco \ --namespacefalco \ --reuse-values \ --values./falcoctl-values.yaml多数据源场景syscalls 插件仅升级时同场景 1同时想用 falcoctl 管理规则与插件时参照场景 4 的 falcoctl 配置。Rulesfiles捆绑时代终结自 v3.0.0 起Chart 不再创建包含以下 rulesfiles 的 ConfigMapapplication_rules.yamlaws_cloudtrail_rules.yamlfalco_rules.local.yamlfalco_rules.yamlk8s_audit_rules.yaml原因是这些文件已随 Falco 镜像内置Chart 侧维护纯属冗余且需随每个 Falco 版本手动同步。但镜像内置方案的弊端是用户必须等待 Falco 新版本才能获得最新规则。更优方案就是前述 falcoctl——从 falcosecurity 组织拉取并安装最新 rulesfiles。注意如果你此前曾错误地自定义过这些文件再部署请改用 custom rules 机制customRules配置项见 values.yaml。放弃falcosecurity/falco镜像与 driver-loader 简化从 Chart v2.0.0 起默认镜像即为falcosecurity/falco-no-driverv2.0.0 仍兼容falcosecurity/falco但 v2.2.0 起该镜像组合已被破坏且不再修复。当前 values.yaml 默认repository: falcosecurity/falco该仓库现已提供 no-driver 语义的镜像。随之而来的是 driver-loader 逻辑简化现在只有一个开关driver.loader.enabledtrue控制 driver-loader init container 的启用/禁用无需再针对不同镜像做组合判断。driver-loader init container 的实现见 pod-template.tpl它会挂载/host/proc、/host/boot、/host/lib/modules等宿主机目录并按driver.kind传入对应参数kmod/modern_ebpf/auto当kindauto时还会注入FALCOCTL_DRIVER_CONFIG_NAMESPACE与FALCOCTL_DRIVER_CONFIG_CONFIGMAP环境变量由 falcoctl 驱动配置写入。升级实操建议先做配置体检把旧 values 中的键与本文总览表逐项比对重点排查falco.grpc*、driver.kindebpf/gvisor、collectors.docker/containerd/cri、falcotalon*、driver.module/driver.modern-bpf等已移除或已改名的配置。9.x Chart 的 removedConfigGuard 会在渲染失败时报错并直接指向 BREAKING-CHANGES.md这是最可靠的校验手段。按依赖顺序迁移先处理 driver 与输出通道9.x/8.x 硬性移除项再迁移容器元数据采集7.x最后评估是否启用 falcoctl3.x 引入的能力可延后启用不影响升级本身。升级前验证镜像工具依赖若使用program_output或自定义 init 脚本依赖镜像内工具确认 distroless 镜像是否满足需求不满足则显式覆盖image.tag为-debian风味。善用 dry-run 与单点发布执行helm upgrade --dry-run观察渲染结果falcoctl 的follow建议只对 rulesfile 工件启用插件跟随可能引入非预期行为。完成上述迁移后你的部署即可平稳落地到当前 Chart 9.x / Falco 0.44.x 的架构默认 distroless 镜像 autodriverkmod / modern_ebpf containerEngine 元数据采集 falcoctl 工件管理同时彻底告别 gRPC 输出、Legacy eBPF 与 gVisor 引擎带来的维护与兼容负担。赞分享云原生运行时防护IDS应用安全【免费下载链接】falcoCloud Native Runtime Security项目地址https://gitcode.com/gh_mirrors/fa/falco点击查看免费下载相关推荐lightweight-charts 从 v3 迁移到 v4 完全指南API 破坏性变更对照与迁移实战lightweight charts 从 v3 迁移到 v4 完全指南API 破坏性变更对照与迁移实战 本文基于 lightweight charts 仓库官前端图表库金融科技数据可视化lightweight-charts v3 迁移到 v4 完整指南API 破坏性变更对照与升级实战lightweight charts v3 迁移到 v4 完整指南API 破坏性变更对照与升级实战 本文以 lightweight charts基于 HTM前端图表库金融科技数据可视化大麦自动抢票改好 5 个配置项开售自动选场次提交订单的实战指南大麦自动抢票改好 5 个配置项开售自动选场次提交订单的实战指南 热门演出开售 3 秒就灰手动点得再快也拼不过刷新速度。ticket purchase 是一GUI 自动化RPA上一篇Shannon全自动AI渗透测试用真实利用证明漏洞下一篇Asciidoctor扩展系统深度解析7种自定义处理器开发完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考