安全修补

本文档介绍了 Google 如何管理 Google Kubernetes Engine (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 漏洞。 Google Cloud 安全团队也会定期发现并修复基于内核的虚拟机 (KVM) 中的漏洞。

适合在许多层级进行 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的 FedRAMP 临时授权运营中，这就要求已知漏洞在特定的时间段内根据其严重性级别（如 FedRAMP 安全控制基准电子表格中“风险评估(RA)”记录 RA-5“漏洞扫描”的控制措施 RA-5 (d) 中所指定）进行修正。

对于每个已知漏洞，GKE 的目标是在相应的时间范围内发布可修复该漏洞的补丁版本。 Google Cloud 的 FedRAMP 临时授权运营不包含 Google Distributed Cloud、GKE on AWS、GKE on Azure 或 GKE 关联集群，但我们的目标是针对这些产品制定相同的修复时间范围。在 GKE 提供补丁版本以修复已知漏洞后，请将集群升级到这些版本，以符合组织的修补时间范围。

漏洞和补丁程序的通信方式

有关漏洞和安全补丁程序的最新信息的最佳来源，可在以下产品的安全公告 Feed 中找到：

  • Google Kubernetes Engine (GKE)
  • Google Distributed Cloud on VMware（纯软件）
  • GKE on AWS
  • GKE on Azure
  • Google Distributed Cloud on Bare Metal（纯软件）

这些公告遵循通用的 Google Cloud 漏洞编号方案，并且在主要 Google Cloud 公告页面和 GKE 版本说明中提供了链接。每个安全公告页面都有一个 RSS 源，供用户订阅更新。

漏洞有时会在有限的时间内保持私密状态（保密期）。保密期有助于在采取相应措施解决漏洞之前，防止提前发布从而导致被广泛利用。在有保密期的情况下，版本说明会在保密期结束前使用“安全更新”来泛指这些漏洞。在保密期结束后，Google 会更新版本说明以包含特定的漏洞。

GKE 安全团队会针对严重级别为“高”和“严重”的漏洞发布安全公告。如果需要客户操作才能解决这些严重程度为“高”和“严重”的漏洞，Google 会通过电子邮件与客户联系。此外，Google 可能还会通过支持渠道就支持合同事宜联系客户。

安装安全补丁的最快方式是什么？

所有集群都会通过 GKE 自动升级功能自动保持修补状态。本部分介绍了如何比自动升级更快地修补特定安全修复，或持续进行修补。通过结合使用测试环境、跨渠道手动升级、加速补丁设置和事件驱动型通知，您可以缩短补丁准备时间。

GKE 会管理各个发布渠道的版本发布，以确保新版本经过资格认证和充分测试。为了缩短补丁发布提前期，您需要了解这些发布的工作方式，然后根据您的具体需求调整默认行为。

对修补后的版本进行浸泡测试，是指在集群上运行该版本一段时间，以观察其稳定性。此流程有助于捕获仅在长时间使用后才会出现在各种环境中的 bug。为确保有足够的过渡时间，GKE 补丁版本会先发布到快速渠道，然后再发布到常规渠道和稳定渠道。版本在成为相应渠道的升级目标之前，也会在每个渠道中进行浸泡。

通过发布序列提前确定补丁的质量并管理发布

如需评估要加速的安全补丁，请使用发布序列在各个环境中发布，先在其他 GKE 集群中测试补丁，然后再升级生产环境。这种方法可让您验证工作负载兼容性，并在 Google 发布安全修复程序后立即发现任何问题。然后，您可以将修补后的版本应用到其余舰队，并控制剩余的过渡时间。

通过加速补丁自动升级减少浸泡延迟

或者，您也可以为集群启用加速补丁自动升级，以便更快地使用补丁。此功能会指示 GKE 绕过补丁更新（尤其是安全补丁）的渠道内过渡时间。如果您使用此方法，Google 建议您在快速渠道上运行测试集群（也使用加速补丁自动升级）来验证补丁。

手动升级到常规渠道和稳定渠道中的更新补丁版本

如果您的生产工作负载位于已在常规渠道或稳定渠道中注册的集群上，并且您需要优先处理特定的安全更新，那么无需退出这些渠道，也无需等待补丁的自动分阶段推出。

如果您已确定修补版本符合条件，则可以手动启动常规或稳定版集群的升级，将其升级到该确切的修补版本，以控制剩余的过渡时间。

通过集群通知自动执行补丁管理

无需监控安全公告网页以获取补丁信息。如需快速以程序化方式接收有关可用补丁的通知，并触发补丁资格认证和升级操作，您可以使用集群通知。

如需接收有关安全公告或预定升级的通知，请配置通知以专门过滤以下事件类型：

借助集群通知，您可以在发生这些事件时接收实时消息。您可以将这些通知集成到安全信息和事件管理 (SIEM) 系统、聊天操作中，或触发自动化测试流水线。