Kube-OVN 是如何自动修复 CVE 的
2025-06-28 00:02:21

这篇博客是内部分享的一个提示文稿，并没有做仔细整理，大体思路就是捕获所有 Kube-OVN 的依赖：操作系统，Golang，程序依赖，环境组件（k8s,kubevirt 等），然后激进的实时更新所有依赖做到动态清零。

Kube-OVN CVEs 问题修复的流程经历了如下几个阶段：

  • 发版/按需统一进行手动修复
  • 每次 commit 检测可修复安全漏洞，手动进行修复
  • master 依赖自动更新，发版分支部分依赖自动更新，少量手动修复
  • 未来目标：所有依赖自动更新，避免手动修复

按需修复

优势：

  • 相比每个安全漏洞单独修复，整体修复频次低
    劣势：
  • 发版集中修复，研发还要兼顾发版期间赶进度，测试，bug 修复，时间压力大
  • 依赖更新没有经过日常验证，存在未知的风险
  • 大部分安全修复工作没有实际意义还需要花费人工精力

每次 Commit 检测修复

增加工作：

优势：

  • 将 CVE 修复打散到平时，发版时时间压力较低
  • 可以快速发版
  • 大部分依赖更新已经得到了日常自动化测试的验证，风险也较低
    劣势：
  • 最后一次提交和发版扫描之间存在时间差，理论上会遗漏一部分 CVE
  • 会干扰平时正常功能提交，bug 修复，提交经常因为不相关的 CVE 问题被阻塞
  • 大量的手动修复

所有依赖自动更新

只要依赖更新版本就尝试更新，不考虑是否是安全更新。尝试解决比 CVE 修复更大的一个问题，自动就解决了 CVE 问题的修复。

我们的依赖项：

  • OS 镜像及其依赖：ubuntu:24.04, apt-get install ....
  • Go 语言版本，以及代码依赖库
  • 上游依赖：OVS, OVN
  • 其他协作组件依赖： kubernetes, kubevirt,multus, metallb, cilium, talos
  • 采用比较激进的更新策略，依赖大版本更新我们也会尝试更新

要做的事情：

优点：

  • 大部分 CVE 会在不知道情况下被修复，少量可在一天内自动修复，特殊情况再手动修复
  • 大量上游的 bugfix，性能提升和新功能被自动合入，软件整体稳定性提升
  • 大量的版本适配验证工作，如 k8s 版本更新，KubeVirt 版本更新的适配验证也都自动进行，风险提前知晓
  • 人工干预量较少

劣势：

  • 依赖更新多比较吵，需要设置聚合策略
  • 更新量太大无法人工测试，需要有自动化测试保证
  • 需要积极适配上游版本变化
  • 存在上游新版本不稳定风险，目前两年内遇到过两次

renovate 相比 dependabot 优势

  • 可以自定义依赖捕获，Dockerfile、Makefile 里的非标准依赖可以捕获
  • 可以在非 master 分支运行
  • 有 auto merge 能力

还未解决的问题

上一页
2025-06-28 00:02:21
下一页