[转载] 回顾过去:纠正未修复的 Kubernetes CVE 记录

举报
yd_266879620 发表于 2026/11/12 00:42:15 2026/11/12
【摘要】 Kubernetes 项目依赖透明性来赋能集群管理员和安全研究人员。 我们做到这一点的一个重要方式是将 CVE 记录发布到常见漏洞和风险数据库。 作为我们持续完善官方 Kubernetes CVE 信息源 努力的一部分,我们发现了一些差异。一些较旧的、未修复问题的 CVE 记录错误地包含了 fixed version 字段。 Kubernetes 安全响应委员会(SRC)将于 2026 年 ...

本文为授权转载,非本账号原创。

原文:回顾过去:纠正未修复的 Kubernetes CVE 记录(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/)

原作者及译者:借由 Pushkar Joglekar (Broadcom / SIG Security)、 Tabitha Sable (Datadog / K8s Security Response Committee / SIG Security) | 译者 Xin Li (DaoCloud) | 2026.05.26

来源:Kubernetes 官方中文博客;许可:CC BY 4.0(参考地址:https://creativecommons.org/licenses/by/4.0/)。保留原作者和译者署名,正文仅做适配博客编辑器的排版与链接格式转换,未改写技术内容。

内容不代表原作者或 Kubernetes 项目对本账号的认可或背书。

Kubernetes 项目依赖透明性来赋能集群管理员和安全研究人员。 我们做到这一点的一个重要方式是将 CVE 记录发布到常见漏洞和风险数据库。 作为我们持续完善官方 Kubernetes CVE 信息源(参考地址:https://kubernetes.io/zh-cn/docs/reference/issues-security/official-cve-feed/) 努力的一部分,我们发现了一些差异。一些较旧的、未修复问题的 CVE 记录错误地包含了 fixed version 字段。

Kubernetes 安全响应委员会(SRC)将于 2026 年 6 月 1 日纠正受影响的 CVE 记录。 这可能导致漏洞扫描器在以前未检测到的地方识别这些漏洞。

为帮助减少混淆,本文提供了多年前披露但仍未修复的三个漏洞的技术更新: CVE-2020-8561、CVE-2020-8562 和 CVE-2021-25740。

为什么我们现在更新这些记录(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#%e4%b8%ba%e4%bb%80%e4%b9%88%e6%88%91%e4%bb%ac%e7%8e%b0%e5%9c%a8%e6%9b%b4%e6%96%b0%e8%bf%99%e4%ba%9b%e8%ae%b0%e5%bd%95)

虽然这些漏洞已经公开多年,但最近生成官方开源漏洞(OSV)文件的工作表明, 它们相应的 CVE 记录并未准确反映其状态。 具体来说,一些记录表明存在 fixed 版本,而实际上, 这些问题是架构设计上的权衡,无法在不破坏基本 Kubernetes 功能的情况下通过代码完全修复。

纠正这些记录对社区至关重要,原因如下:

  • 自动化保真度:现代漏洞扫描器依赖精确的版本范围。 不准确的 fixed 标签会导致漏报,给用户一种虚假的安全感。
  • 风险文档化:通过将这些正式列为 unfixed, 我们确保平台提供商和管理员意识到持续需要管理缓解措施。

为完整性起见,我们还应该提到 CVE-2020-8554(参考地址:https://www.cve.org/cverecord?id=CVE-2020-8554) 是一个未修复的 CVE,其正确的 CVE 记录表明它影响所有版本。 该记录也将被更新为使用更标准的版本号格式。

未修复的架构风险技术分析(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#%e6%9c%aa%e4%bf%ae%e5%a4%8d%e7%9a%84%e6%9e%b6%e6%9e%84%e9%a3%8e%e9%99%a9%e6%8a%80%e6%9c%af%e5%88%86%e6%9e%90)

以下漏洞不会被 Kubernetes 项目修复。 GitHub Issue 仍然是了解这些缺陷技术细节的最佳参考。

CVE-2020-8561(参考地址:https://github.com/kubernetes/kubernetes/issues/104720):kube-apiserver 中的 Webhook 重定向(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#cve-2020-8561-kube-apiserver-%e4%b8%ad%e7%9a%84-webhook-%e9%87%8d%e5%ae%9a%e5%90%91)

  • 严重性:中(4.1)。
  • 问题:kube-apiserver 在与准入 Webhook 通信时遵循 HTTP 重定向。 具有配置 AdmissionWebhookConfiguration 能力的角色可以将 API 服务器请求重定向到内部私有网络。
  • 为什么仍未修复:限制此行为需要破坏许多合法集成所依赖的标准 HTTP 客户端行为。
  • 缓解措施:将 API 服务器日志级别设置为小于 10(以防止记录响应正文) 并禁用动态性能分析(--profiling=false)以防止未经授权的日志级别更改。

CVE-2020-8562(参考地址:https://github.com/kubernetes/kubernetes/issues/101493):通过 DNS TOCTOU 绕过代理(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#cve-2020-8562-%e9%80%9a%e8%bf%87-dns-toctou-%e7%bb%95%e8%bf%87%e4%bb%a3%e7%90%86)

  • 严重性:低(3.1)。
  • 问题:API 服务器代理中的检查时间到使用时间(TOCTOU)竞态条件允许用户绕过 IP 限制。 系统执行 DNS 检查来验证 IP,但随后执行第二次解析以建立实际连接,攻击者可以操纵这一点。
  • 为什么仍未修复:修复此问题需要固定已解析的 IP,但这会破坏复杂的分域 DNS 或动态 IP 环境。
  • 缓解措施:为 API 服务器使用本地 DNS 缓存服务器(如 dnsmasq)并配置 min-cache-ttl 以在检查和连接之间强制执行一致的响应。

CVE-2021-25740(参考地址:https://github.com/kubernetes/kubernetes/issues/103675):通过 Endpoints 跨命名空间转发(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#cve-2021-25740-%e9%80%9a%e8%bf%87-endpoints-%e8%b7%a8%e5%91%bd%e5%90%8d%e7%a9%ba%e9%97%b4%e8%bd%ac%e5%8f%91)

  • 严重性:低(3.1)。
  • 问题:Endpoints 和 EndpointSlice API 对象中的设计缺陷允许用户手动指定 IP 地址, 可用于将 LoadBalancer 或 Ingress 指向其他命名空间中的后端。
  • 为什么仍未修复:这是许多网络工具和 Operator 使用的 Endpoints API 的基本功能。
  • 缓解措施:限制对 Endpoints(遗留)和 EndpointSlices 的写访问。 自 Kubernetes 1.22 以来,Kubernetes RBAC 授权模式不再将这些权限包含在默认的 edit 和 admin ClusterRole 中。 该移除适用于使用 Kubernetes v1.22 创建的集群; 对于从旧版本升级的集群,管理员应手动审计并协调 system:aggregate-to-edit ClusterRole。

说明:

2026 年 6 月 1 日,这些 CVE 记录将被更新以正确反映所有版本都受影响的事实。 你可能会看到它们开始出现在漏洞扫描器结果中。

管理员需要的操作(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#%e7%ae%a1%e7%90%86%e5%91%98%e9%9c%80%e8%a6%81%e7%9a%84%e6%93%8d%e4%bd%9c)

Kubernetes 项目建议采用通过配置确保安全方法来管理这些持续风险:

漏洞操作项严重性评分(等级)命令/配置
CVE-2020-8561限制日志详细程度4.1(中)确保 --v 设置为 < 10 且 --profiling=false。
CVE-2020-8562强制 DNS 一致性3.1(低)在控制平面节点上部署 dnsmasq 或类似的缓存解析器。
CVE-2021-25740加固 RBAC3.1(低)使用 kubectl auth reconcile 从广泛角色中移除 Endpoints 写访问权限。

CVE-2021-25740 的 RBAC 操作适用于你的集群使用 RBAC 授权模式的场景, 这是使用标准 Kubernetes 工具创建的集群的默认设置。 管理员应在非生产环境中独立测试和验证这些配置,根据其特定的威胁模型和风险承受能力评估架构风险。

结语:通过透明性走向成熟(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/#%e7%bb%93%e8%af%ad-%e9%80%9a%e8%bf%87%e9%80%8f%e6%98%8e%e6%80%a7%e8%b5%b0%e5%90%91%e6%88%90%e7%86%9f)

协调这些记录的努力是安全生态系统走向成熟的标志。 通过摆脱“仅打补丁”的心态并准确记录架构债务, Kubernetes 项目为社区提供了保护现代云原生基础设施所需的高保真数据。

我们要感谢发现这些风险的安全研究人员——QiQi Xu、Javier Provecho 等人, 以及继续完善我们官方源的 SIG Security Tooling 贡献者。 特别感谢 Rory McCune 通过他的博客文章分享了有关这些 CVE 的信息。

  • ←上一页(参考地址:https://kubernetes.io/zh-cn/blog/2026/05/20/etcd-370-beta/)
  • 下一页→(参考地址:https://kubernetes.io/zh-cn/blog/2026/06/01/dashboard-to-headlamp/)
最后修改 May 31, 2026 at 7:27 PM PST: [zh-cn]Add blog: reconciling-unfixed-kubernetes-cves (5f56dca6ec)(参考地址:https://github.com/kubernetes/website/commit/5f56dca6eca204f2b3351cc70aa11f8c9b12dd39)
【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。