本文档介绍了 Google 如何管理 Google Kubernetes Engine (GKE) 的安全漏洞和补丁。这些信息可能对 为需要 战略性协助来解决的安全问题或漏洞（例如突发事件和支持团队上报的问题）提供支持的安全专家很有用。
修补责任共担
如 GKE 责任共担中所述，修补是 Google 与客户共同承担的责任。
如何发现漏洞
Google 在主动式安全设计和强化工作方面进行了大量投资，但即使是设计最好的软件系统也可能会有漏洞。为了发现这些漏洞并在漏洞被利用之前加以修补，Google 为多个前端进行了大量投资。
在修补过程中，GKE 是一个操作系统 (OS) 层，其中容器在顶层运行。操作系统、Container-Optimized OS 或 Ubuntu 已经过强化，并且包含运行容器所需的最低软件版本。GKE 功能作为容器在基础映像之上运行。GKE 始终致力于减少系统组件的依赖项数量，这有助于缩小攻击面并提高漏洞管理效率。例如，GKE 系统组件可能会尽可能使用最小的基础映像。
Google 通过以下方式识别并修复漏洞和缺失补丁程序：
Container-Optimized OS：Google 会扫描映像以识别潜在漏洞和缺失补丁程序。Container-Optimized OS 团队会审核并解决问题。
Ubuntu：Canonical 向 Google 提供已应用所有可用安全补丁程序的操作系统版本。
Google 使用 Container Registry Artifact Analysis 扫描容器，以发现 Kubernetes 和 Google 管理的容器中存在的漏洞和缺失补丁。如果提供了修复，则扫描程序会自动开始修补和发布流程。
除了自动扫描之外，Google 还会通过以下方式发现并修补扫描程序未知的漏洞。
Google 会在所有平台上执行自己的审核、渗透测试和漏洞发现。如需查看平台列表，请参阅上一部分 修补责任共担。
Google 和可靠的第三方安全供应商内的专业团队负责开展他们自己的攻击调查。Google 还与 CNCF 协作，在 Kubernetes 安全审核方面提供了大量组织和技术咨询专业知识。
Google 通过 多个漏洞奖励计划积极与安全研究社区互动。 一个专门的 Google Cloud 漏洞奖励计划提供 大量奖励金， 针对每年发现的最佳云漏洞 提供 133,337 美元。在 GKE 中，有一项计划用来奖励 能够 破坏我们的安全控制措施的安全研究人员。 此计划涵盖所有 GKE 软件依赖项。
Google 与其他行业以及开源软件合作伙伴协作，开源软件合作伙伴会在漏洞公开发布之前共用漏洞、安全研究和补丁程序。这项协作的目标是在公开宣布漏洞之前，先修补大型互联网基础架构。在某些情况下，Google 会将发现的漏洞公布在此社区中。例如，Google 的 Project Zero 发现并公开了 Spectre 和 Meltdown 漏洞。安全团队也会定期发现并修复基于内核的虚拟机 (KVM) 中的漏洞。 Google Cloud
适合在许多层级进行 Google 的安全协作。有时，安全协作通过计划正式进行，在这种形式下，组织会注册以接收有关产品（例如 Kubernetes和 Envoy）的软件漏洞的预发布通知。由于我们还与许多开源项目（例如 Linux 内核、容器运行时、虚拟化技术等）互动，从而以非正式方式实现协作。
对于 Kubernetes，Google 是安全响应委员会 (Security Response Committee, SRC) 的活跃成员及创始会员，其编写了安全发布流程的大部分内容。Google 是 Kubernetes 分发商列表 的成员，该成员会预先收到漏洞通知，并且已经参与 近乎所有严重 Kubernetes 安全漏洞的分类、修补、缓解措施开发和沟通。Google 还发现了多个 Kubernetes 漏洞，例如 CVE-2019-11254、 CVE-2019-11255 和 CVE-2021-25741。
虽然在这些过程之外发现和修补的安全漏洞不太严重，但大多数严重安全漏洞会通过先前列出的其中一个渠道进行私密报告。提前报告可让 Google 在漏洞公开发布之前有时间研究漏洞对 GKE 的影响、制定修补或缓解措施，并为客户准备建议和沟通。可能的话，Google 会在公开发布漏洞之前，先修补所有集群。
漏洞的分类方式
除了设置良好的默认值、安全强化配置和托管组件之外，GKE 还在加强整个堆栈（包括操作系统、容器、Kubernetes 和网络层）的安全性方面进行了大量投资。组合使用这些方法有助于降低漏洞的影响和产生漏洞的可能性。
GKE 安全团队根据 Kubernetes 漏洞评分 系统对漏洞进行分类。分类会考虑诸多因素，包括 GKE 配置和安全加固。 由于这些因素以及 GKE 在安全性方面所做的投资，GKE 漏洞分类可能与其他分类来源有所不同。
下表介绍了漏洞严重级别分类：
| 严重级别 | 说明 |
|---|---|
| 严重 | 所有集群都存在的漏洞，容易被未通过身份验证的远程攻击者利用，从而导致完整的系统遭到破解。 |
| 高 | 许多集群都存在的漏洞，容易被攻击者利用，从而导致机密性、完整性或可用性遭受损失。 |
| 中 | 某些集群存在的漏洞，在这些集群中，机密性、完整性或可用性遭受的损失受到通用配置、利用本身的困难、必需的访问权限或用户互动限制。 |
| 低 | 所有其他漏洞。此类攻击的可能性不大，且攻击造成的后果也是有限的。 |
如需查看 漏洞、修复方案和缓解措施及其评分示例，请参阅 安全公告。
GKE 集群的漏洞修补方式
修补漏洞涉及升级到新的 GKE 版本号。GKE 版本包括操作系统的版本控制组件、Kubernetes 组件以及构成 GKE 平台的其他容器。修复某些漏洞只需要升级控制层面（由 Google 在 GKE 上自动执行），而修复其他漏洞则需要同时升级控制平面和节点。
为了确保集群能够抵御所有严重级别的漏洞，我们 建议遵循 GKE 集群升级的最佳实践，以帮助 确保您的集群及时收到安全补丁。
Google 建议至少每月升级一次 Kubernetes 集群。如需查看平台列表，请参阅上一部分 修补责任共担。
某些安全扫描程序或手动版本检查可能会错误地假定 runc 或 containerd 等组件缺少特定的上游安全补丁。GKE 会定期修补组件，并仅在需要时执行软件包版本升级，这意味着 GKE 组件在功能上与其上游对应组件类似，即使 GKE 组件的版本号与上游版本号不匹配也是如此。如需详细了解特定 CVE，请参阅 GKE 安全公告。
修补时间轴
Google 的目标是在一段时间内缓解检测到的漏洞带来的相应风险。GKE 包含在 Google Cloud's FedRAMP 临时授权运营中 ，这就要求已知漏洞在特定的 时间范围内根据其严重级别（如 FedRAMP 安全控制基准电子表格中风险评估 (RA) 记录 RA-5“漏洞扫描”的控制项 RA-5[d] 中所指定）进行修正。
对于每个已知漏洞，GKE 的目标是在相应的时间范围内发布可修复该漏洞的补丁版本。 在 GKE 提供补丁版本以修复已知漏洞后，请将集群升级到这些版本，以符合组织的修补时间范围。
漏洞和补丁程序的通信方式
如需了解有关 GKE 的漏洞和安全 补丁程序的最新信息，请参阅 安全公告。
从 2026 年 6 月 1 日起，GKE 不会针对 Google Distributed Cloud（纯软件）、GKE on AWS 或 GKE on Azure 发布安全公告。如需查看这些产品的最新安全公告和漏洞修复，请参阅以下文档：
漏洞有时会在有限的时间内保持私密状态（保密期）。 保密期有助于在采取相应措施解决漏洞之前，防止提前发布从而导致被广泛利用。在有保密期的情况下，版本说明会在保密期结束前使用“安全更新”来泛指这些漏洞。在保密期结束后，Google 会更新版本说明以包含特定的漏洞。
GKE 安全团队会针对严重级别为“高”和“严重”的漏洞发布安全公告。如果需要客户操作才能解决这些严重程度为“高”和“严重”的漏洞，Google 会通过电子邮件与客户联系。此外，Google 可能还会通过支持渠道就支持合同事宜联系客户。
安装安全补丁的最快方式是什么？
所有集群都将通过 GKE 自动升级功能自动保持修补状态。本部分介绍了如何比自动升级更快地修补特定安全修复程序，或如何持续修补。通过结合使用测试环境、跨渠道手动升级、加速补丁设置和事件驱动型通知，您可以缩短修补提前期。
GKE 会管理跨发布渠道的版本发布，以确保新版本符合条件并经过过渡。如需缩短修补提前期，您需要了解这些发布的工作原理，然后根据您的具体需求调整默认行为。
过渡修补后的版本涉及在集群上运行该版本一段时间以观察稳定性。此过程有助于捕获仅在不同环境中长时间使用后才会出现的 bug。为了确保有足够的过渡时间，GKE 补丁版本 会先在 快速渠道中推出，然后依次在常规渠道和稳定渠道中推出。 版本也会在每个渠道中过渡，然后才会成为该渠道的升级目标。
尽早评估补丁，并使用发布顺序管理发布
如需评估要加速的安全补丁，请使用发布顺序在 各个环境中发布， 在升级生产 环境之前先在其他 GKE 集群中测试补丁。 通过这种方法，您可以验证工作负载兼容性，并在 Google 发布安全修复程序后立即发现任何问题。然后，您可以将修补后的版本应用于其余舰队，并控制剩余的过渡时间。
通过加速补丁自动升级缩短过渡延迟时间
或者，您可以为集群启用加速补丁自动升级，以便更快地使用补丁。此功能会指示 GKE 绕过补丁更新（尤其是安全补丁）的渠道内过渡时间。如果您使用这种方法，Google 建议在快速渠道（也使用加速补丁自动升级）上运行测试集群，以评估补丁。
在常规渠道和稳定渠道中手动升级到较新的补丁版本
如果您的生产工作负载位于已在常规渠道或 稳定渠道中注册的集群上，并且您需要优先处理特定的 安全更新，则无需离开这些渠道，也无需等待补丁的 自动分阶段发布。
如果您已评估修补后的版本， 您可以在常规渠道或稳定渠道中手动启动 集群升级到该确切 补丁版本，以控制剩余的过渡时间。
使用集群通知自动执行修补管理
您无需监控安全公告网页来获取补丁信息。如需快速以编程方式获取有关可用补丁的通知，并 触发补丁评估和升级操作，您可以使用 集群 通知。
如需获取有关安全公告或计划升级的通知，请将通知配置为专门过滤以下事件类型：
借助集群通知，您可以在这些事件发生时收到实时消息。您可以将这些通知集成到安全信息和事件管理 (SIEM) 系统、聊天操作中，或触发自动测试流水线。