安全修补
本文档介绍了 Google 如何管理 Google Kubernetes Engine (GKE) 和 GKE Enterprise 的安全漏洞和补丁。除非另有说明，否则 GKE Enterprise 同时包含 GKE 和 GKE Enterprise 平台。
修补共担责任
修补是 Google 与客户共同承担的责任。不同的平台有不同的共担责任。如需了解详情，请参阅每个平台的以下主题：
如何发现漏洞
Google 在主动式安全设计和强化工作方面进行了大量投资，但即使是设计最好的软件系统也可能会有漏洞。为了发现这些漏洞并在漏洞被利用之前加以修补，Google 为多个前端进行了大量投资。
在修补过程中，GKE Enterprise 是一个操作系统 (OS) 层，其中容器在顶部运行。操作系统、Container-Optimized OS 或 Ubuntu 已经过强化，并且包含运行容器所需的最低软件版本。GKE Enterprise 功能作为容器在基础映像的基础上运行。
Google 通过以下方式识别并修复漏洞和缺失补丁程序：
Container-Optimized OS：Google 会扫描映像以识别潜在漏洞和缺失补丁程序。Container-Optimized OS 团队会审核并解决问题。
Ubuntu：Canonical 向 Google 提供已应用所有可用安全补丁程序的操作系统版本。
Google 使用 Container Registry Artifact Analysis 扫描容器，以发现 Kubernetes 和 Google 管理的容器中存在的漏洞和缺失补丁。如果提供了修复，则扫描程序会自动开始修补和发布流程。
除了自动扫描之外，Google 还会通过以下方式发现并修补扫描程序未知的漏洞。
Google 会在所有 GKE Enterprise 平台上执行自己的审核、渗透测试和漏洞发现。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 漏洞。
虽然在这些过程之外发现和修补的安全漏洞不太严重，但大多数严重安全漏洞会通过先前列出的其中一个渠道进行私密报告。提前报告可让 Google 在漏洞公开发布之前有时间研究漏洞对 GKE Enterprise的影响、开发补丁程序或缓解措施，并为客户准备建议和沟通。可能的话，Google 会在公开发布漏洞之前，先修补所有集群。
漏洞的分类方式
除了设置良好的默认值、安全强化配置和托管组件之外，GKE 还在加强整个堆栈（包括操作系统、容器、Kubernetes 和网络层）的安全性方面进行了大量投资。组合使用这些方法有助于降低漏洞的影响和产生漏洞的可能性。
GKE Enterprise 安全团队根据 Kubernetes 漏洞评分系统对漏洞进行分类。分类会考虑诸多因素，包括 GKE 和 GKE Enterprise 配置以及安全强化。由于这些因素以及 GKE 在安全性方面所做的投资，GKE 和 GKE Enterprise 漏洞分类可能与其他分类来源有所不同。
下表介绍了漏洞严重级别分类：
| 严重级别 | 说明 |
|---|---|
| 严重 | 所有集群都存在的漏洞，容易被未通过身份验证的远程攻击者利用，从而导致完整的系统遭到破解。 |
| 高 | 许多集群都存在的漏洞，容易被攻击者利用，从而导致机密性、完整性或可用性遭受损失。 |
| 中 | 某些集群存在的漏洞，在这些集群中，机密性、完整性或可用性遭受的损失受到通用配置、利用本身的困难、必需的访问权限或用户互动限制。 |
| 低 | 所有其他漏洞。此类攻击的可能性不大，且攻击造成的后果也是有限的。 |
如需查看漏洞、修复方案和缓解措施及其评分示例，请参阅安全公告。
漏洞的修补方式
修补漏洞需要升级到新的 GKE 或 GKE Enterprise 版本号。GKE 和 GKE Enterprise 版本包括操作系统的版本控制组件、Kubernetes 组件以及构成 GKE Enterprise 平台的其他容器。修复某些漏洞只需要升级控制层面（由 Google 在 GKE 上自动执行），而修复其他漏洞则需要同时升级控制平面和节点。
为了避免经过修补和强化的集群受到所有严重程度的漏洞的攻击，我们建议使用在 GKE 上自动升级节点（默认情况下已启用）。对于在发布渠道中注册的集群，补丁版本会升级，因为它们满足每个渠道的资格要求。如果您在 GKE 补丁版本到达集群的渠道之前需要该版本，并且该补丁版本的次要版本与集群的发布渠道中提供的次要版本相同，您可以手动升级到该补丁版本。
在其他 GKE Enterprise 平台上，Google 建议至少每月升级一次 GKE Enterprise 组件。
某些安全扫描程序或手动版本检查可能会错误地认为 runc 或 containerd 等组件缺少特定的上游安全补丁。GKE 会定期修补组件并在需要时执行软件包升级，这意味着 GKE 组件在功能上与其上游对应组件类似。如需详细了解特定 CVE，请参阅 GKE 安全公告。
修补时间轴
Google 的目标是在一段时间内缓解检测到的漏洞带来的相应风险。GKE 包含在 Google Cloud 的 FedRAMP 临时授权运营中，这就要求已知漏洞在特定的时间段内根据其严重性级别（如 FedRAMP RA-5d 中所指定）进行修正。Google Cloud 的 FedRAMP 临时授权运营在 AWS 上不包含 GKE on VMware 和 GKE on AWS，但我们的目标是针对这些产品制定相同的修正时间范围。
漏洞和补丁程序的通信方式
有关漏洞和安全补丁程序的最新信息的最佳来源，可在以下产品的安全公告 Feed 中找到：
- GKE
- GKE on VMware
- GKE on AWS
- GKE on Azure
- GKE on Bare Metal
这些公告遵循通用的 Google Cloud 漏洞编号方案，并且在 Google Cloud 公告主页和 GKE 版本说明中提供了链接。每个安全公告页面都有一个 RSS 源，供用户订阅更新。
漏洞有时会在有限的时间内保持私密状态（保密期）。保密期有助于在采取相应措施解决漏洞之前，防止提前发布从而导致被广泛利用。在有保密期的情况下，版本说明会在保密期结束前使用“安全更新”来泛指这些漏洞。在保密期结束后，Google 会更新版本说明以包含特定的漏洞。
GKE Enterprise 安全团队会针对严重程度为“高”和“严重”的漏洞发布安全公告。如果需要客户操作才能解决这些严重程度为“高”和“严重”的漏洞，Google 会通过电子邮件与客户联系。此外，Google 可能还会通过支持渠道就支持合同事宜联系客户。