Kubernetes 官方重新定义多个历史 CVE：有些风险，从未真正被修复¶

参阅 Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs

如果你的漏洞扫描平台最近突然发现 Kubernetes 集群“新增”了几个 CVE，不必惊慌。这并不意味着 Kubernetes 出现了新的安全漏洞，而是社区正在重新修正过去对于部分风险的认知和记录方式。

Kubernetes 安全响应委员会（SRC）宣布，于 2026 年 6 月 1 日修正部分历史 CVE 的元数据记录。修正后，一些企业的漏洞扫描系统可能突然出现“新增漏洞”，但实际上：

❌ 这些漏洞不是新发现的
❌ 也不是某个版本升级引入的
✅ 而是此前错误地标记了“已修复版本”，现在恢复了真实状态——这些风险实际上从未被代码彻底修复。

涉及哪些 CVE？¶

本次主要涉及：

CVE	严重性	问题描述	为什么仍未修复	临时规避措施
CVE-2020-8561	中（4.1）	kube-apiserver 与准入 Webhook 通信时会遵循 HTTP 重定向，拥有配置 AdmissionWebhookConfiguration 权限的用户可将 API 服务器请求重定向至内部私有网络。	限制重定向行为会破坏许多合法集成所依赖的标准 HTTP 客户端行为。	将 API 服务器日志级别设置为小于 10，避免记录响应正文；同时禁用动态性能分析（`--profiling=false`），防止未经授权修改日志级别。
CVE-2020-8562	低（3.1）	API 服务器代理中的 DNS TOCTOU（检查时间到使用时间）竞态条件允许用户绕过 IP 限制。系统先执行 DNS 校验，再进行第二次解析建立连接，攻击者可利用两次解析结果不一致实施攻击。	修复需要固定已解析的 IP 地址，但会破坏复杂的分域 DNS 或动态 IP 环境。	为 API 服务器使用本地 DNS 缓存服务器（如 `dnsmasq`），并配置 `min-cache-ttl`，确保检查与连接期间返回一致的 DNS 结果。
CVE-2021-25740	低（3.1）	Endpoints 和 EndpointSlice API 对象允许用户手动指定 IP 地址，可利用将 LoadBalancer 或 Ingress 转发到其他命名空间中的后端服务。	手动指定 Endpoint 地址是许多网络工具和 Operator 所依赖的基础功能。	限制对 Endpoints 和 EndpointSlices 的写权限。自 Kubernetes 1.22 起，默认 `edit` 和 `admin` ClusterRole 已移除这些权限；从旧版本升级的集群应手动审计并调整 `system:aggregate-to-edit` ClusterRole。

此外，社区再次强调：

CVE-2020-8554 仍属于 Kubernetes 已知的架构性风险。

为什么这些问题至今没有“修复”？¶

这些问题有一个共同特点：它们并非传统意义上的“代码缺陷”，而是 Kubernetes 为兼顾灵活性、兼容性和可扩展性所做出的架构性安全权衡。

例如：

禁止 HTTP 重定向可能破坏大量现有 Webhook 集成；
固定 DNS 解析结果可能影响复杂网络环境下的服务发现；
禁止手动指定 Endpoint 地址，则会影响大量网络插件和 Operator 的正常工作。

因此，这类风险不存在简单的“升级修复”路径，而需要通过权限治理、网络隔离和平台安全能力进行持续缓解。

为什么这件事值得关注？¶

很多企业的安全运营流程已经形成固定模式：发现 CVE → 升级版本 → 漏洞消失。

但 Kubernetes 的这些案例提醒我们： 并非所有安全问题都能通过升级解决。

在云原生时代，越来越多的风险来自：

配置错误
权限设计不当（RBAC）
网络边界过宽
多租户隔离不足
DNS、日志、控制面的安全配置问题

换句话说： 安全能力正在从“补丁管理”逐渐转向“平台治理”。

AI 基础设施会进一步放大这些风险¶

对于 AI 基础设施而言，这一点尤为重要。

AI 平台通常具备以下特点：

多租户共享 Kubernetes 集群；
大量动态创建和销毁的工作负载；
GPU、存储和网络资源高度共享；
大量第三方组件、模型服务和推理框架接入；
更复杂的权限体系和资源调度策略。

这些特点会进一步放大 Kubernetes 架构性风险带来的安全挑战。

因此，AI 基础设施建设需要考虑的不仅是漏洞修复，更是如何构建持续治理风险的能力。

企业应该如何应对？¶

1️⃣ 不要把“未修复 CVE”简单视为升级任务¶

首先需要理解漏洞成因：

是否属于架构限制？
是否存在现实攻击路径？
是否有替代缓解措施？
是否会对当前业务场景产生实际影响？

很多情况下，升级版本并不会让风险消失。

2️⃣ 建立 Kubernetes 基线加固体系¶

包括：

✅ 最小权限 RBAC
✅ 控制平面安全配置
✅ Admission 策略治理
✅ 网络隔离与 NetworkPolicy
✅ 审计与可观测性建设
✅ 配置持续扫描与合规检查

3️⃣ 从“漏洞修复”走向“风险治理”¶

企业需要回答的问题不再是 “我升级到哪个版本？”

而是 “我的平台是否具备抵御这类风险的防护能力？”

这意味着企业需要建立：

持续的配置审计能力；
多租户隔离能力；
集群基线加固能力；
安全策略自动化能力；
面向 Day-2 运维的风险治理能力。

未来的安全建设目标，不再是简单追求“零 CVE”，而是确保风险始终处于可控状态。

DaoCloud 观点¶

作为 Kubernetes 安全响应委员会（Security Response Committee，SRC）成员，DaoCloud 持续参与 Kubernetes 安全漏洞响应和社区治理工作。

此次历史 CVE 元数据修正，再次说明了一个事实： 并非所有安全风险都能通过升级版本消失，也并非所有 CVE 都存在明确的补丁路径。

对于企业而言，真正需要建设的是持续治理风险的能力，而不是单纯追求“零 CVE”。云原生和 AI 基础设施安全的核心，正在从漏洞管理演进为风险治理。

这也是 DaoCloud 长期坚持的平台建设理念：

将安全基线内建到 Kubernetes 生命周期管理之中；
将权限、网络和配置治理能力前置；
通过平台工程实现多集群、多租户统一治理；
将安全能力作为 AI 基础设施的默认能力，而非事后补丁。

通过 AI 平台工程能力，DaoCloud 致力于将安全能力融入 Kubernetes 全生命周期，实现从“漏洞响应”向“持续治理”的转变，让企业能够从“发现漏洞”走向“持续降低风险”。

Note

安全的终点，不是零漏洞；而是即使漏洞无法彻底消失，风险依然可控。

真正的企业级 AI 基础设施安全，不是等待漏洞出现后再修补，而是在平台设计之初，就让风险具备可治理、可观测、可持续演进的能力。

Tip

关注 DaoCloud，持续获取 Kubernetes、云原生安全与 AI 基础设施的一线实践。