安全公告归档

本页面包含以下产品 2020 年之前的所有安全公告的历史归档：

Google Kubernetes Engine (GKE)
Google Distributed Cloud

如需查看最新的安全公告，请参阅安全公告页面。

GKE 安全公告

2019 年 11 月 14 日

发布日期：2019 年 11 月 14 日
更新日期：2019 年 11 月 14 日

说明严重程度备注

说明	严重程度	备注
Kubernetes 披露了 kubernetes-csi `external-provisioner`、`external-snapshotter` 和 `external-resizer` Sidecar 中存在的一个安全问题，此问题会影响到容器存储接口 (CSI) 驱动程序中捆绑的 Sidecar 的大多数版本。如需了解详情，请参阅 Kubernetes 披露信息。该怎么做？此漏洞不会影响任何代管 GKE 组件。如果您在运行 GKE 1.12 版或更高版本的 GKE Alpha 版集群中管理自己的 CSI 驱动程序，则可能会受此漏洞影响。如果您受到影响，请联系您的 CSI 驱动程序供应商，以获得升级说明。该补丁程序解决了哪些漏洞？ CVE-2019-11255：此 CVE 是 `kubernetes-csi` `external-provisioner`、`external-snapshotter` 和 `external-resizer` Sidecar 中的一个漏洞，可能允许未经授权的卷数据访问或变更。这会影响到 CSI 驱动程序内捆绑的 Sidecar 的大多数版本。	中	CVE-2019-11255

Kubernetes 披露了 kubernetes-csi external-provisioner、external-snapshotter 和 external-resizer Sidecar 中存在的一个安全问题，此问题会影响到容器存储接口 (CSI) 驱动程序中捆绑的 Sidecar 的大多数版本。如需了解详情，请参阅 Kubernetes 披露信息。

该怎么做？
此漏洞不会影响任何代管 GKE 组件。如果您在运行 GKE 1.12 版或更高版本的 GKE Alpha 版集群中管理自己的 CSI 驱动程序，则可能会受此漏洞影响。如果您受到影响，请联系您的 CSI 驱动程序供应商，以获得升级说明。

该补丁程序解决了哪些漏洞？
CVE-2019-11255：此 CVE 是 kubernetes-csi external-provisioner、external-snapshotter 和 external-resizer Sidecar 中的一个漏洞，可能允许未经授权的卷数据访问或变更。这会影响到 CSI 驱动程序内捆绑的 Sidecar 的大多数版本。

中

CVE-2019-11255

2019 年 11 月 12 日

发布日期：2019 年 11 月 12 日
更新日期：2019 年 11 月 12 日

说明严重程度备注

说明	严重程度	备注
Intel 披露了多个可能允许在推测性执行与微架构状态之间进行交互，从而导致数据泄露的 CVE。如需了解详情，请参阅 Intel 披露信息。运行 Kubernetes Engine 的主机基础架构会将客户工作负载彼此隔离。除非您在自己的多租户 GKE 集群内运行不受信任的代码，并且在使用 N2、M2 或 C2 节点，否则无需执行进一步操作。N1 节点上的 GKE 实例无需采取新的操作。如果您运行的是 Google Distributed Cloud，则数据泄露的可能性取决于所用的硬件。请将您的基础架构与 Intel 披露信息对照比较。该怎么做？只有在您使用包含 N2、M2 或 C2 节点的节点池并且这些节点在您自己的多租户 GKE 集群内运行不受信任的代码时，您才会受到影响。重启您的节点以应用补丁程序。如需重启节点池中的所有节点，最简单的方法就是使用升级操作，强制所有受影响的节点池中的节点重启。注意：在升级过程中，您不需要更改版本。您可以使用 `cluster-version` 标志，启动到相同节点版本的升级。该补丁程序解决了哪些漏洞？该补丁程序缓解了以下漏洞： CVE-2019-11135：此 CVE 也称为 TSX 异步中止 (TAA)。TAA 提供了使用与微架构数据抽样 (MDS) 相同的微架构数据结构实现数据渗漏的另一种途径。 CVE-2018-12207 这是一种影响虚拟机主机的拒绝服务攻击 (DoS) 漏洞，允许恶意客机导致未受保护的主机崩溃。此 CVE 也称为“页面大小更改时机器检查错误”。此问题不会影响 GKE。	中	CVE-2019-11135 CVE-2018-12207

Intel 披露了多个可能允许在推测性执行与微架构状态之间进行交互，从而导致数据泄露的 CVE。如需了解详情，请参阅 Intel 披露信息。

运行 Kubernetes Engine 的主机基础架构会将客户工作负载彼此隔离。除非您在自己的多租户 GKE 集群内运行不受信任的代码，并且在使用 N2、M2 或 C2 节点，否则无需执行进一步操作。N1 节点上的 GKE 实例无需采取新的操作。

如果您运行的是 Google Distributed Cloud，则数据泄露的可能性取决于所用的硬件。请将您的基础架构与 Intel 披露信息对照比较。

该怎么做？

只有在您使用包含 N2、M2 或 C2 节点的节点池并且这些节点在您自己的多租户 GKE 集群内运行不受信任的代码时，您才会受到影响。

重启您的节点以应用补丁程序。如需重启节点池中的所有节点，最简单的方法就是使用升级操作，强制所有受影响的节点池中的节点重启。

注意：在升级过程中，您不需要更改版本。您可以使用 cluster-version 标志，启动到相同节点版本的升级。

该补丁程序解决了哪些漏洞？

该补丁程序缓解了以下漏洞：

CVE-2019-11135：此 CVE 也称为 TSX 异步中止 (TAA)。TAA 提供了使用与微架构数据抽样 (MDS) 相同的微架构数据结构实现数据渗漏的另一种途径。

CVE-2018-12207 这是一种影响虚拟机主机的拒绝服务攻击 (DoS) 漏洞，允许恶意客机导致未受保护的主机崩溃。此 CVE 也称为“页面大小更改时机器检查错误”。此问题不会影响 GKE。

中

CVE-2019-11135
CVE-2018-12207

2019 年 10 月 22 日

发布日期：2019 年 10 月 22 日
更新日期：2019 年 10 月 22 日

说明	严重程度	备注
CVE-2019-16276 描述了近期在 Go 编程语言中发现的一个漏洞。此漏洞可能会影响使用身份验证代理的 Kubernetes 配置。如需了解详情，请参阅 Kubernetes 披露信息。 Kubernetes Engine 不允许配置身份验证代理，因此不会受到此漏洞的影响。	无	CVE-2019-16276

说明

严重程度

备注

CVE-2019-16276 描述了近期在 Go 编程语言中发现的一个漏洞。此漏洞可能会影响使用身份验证代理的 Kubernetes 配置。如需了解详情，请参阅 Kubernetes 披露信息。

Kubernetes Engine 不允许配置身份验证代理，因此不会受到此漏洞的影响。

无

CVE-2019-16276

2019 年 10 月 16 日

发布日期：2019 年 10 月 16 日
更新日期：2019 年 10 月 24 日

说明	严重程度	备注
2019 年 10 月 24 日更新：经过修补的版本现已在所有区域推出。近期在 Kubernetes 中发现了一个漏洞（如 CVE-2019-11253 中所述），该漏洞导致任何有权发出 POST 请求的用户都可以在 Kubernetes API 服务器上执行远程拒绝服务攻击。Kubernetes 产品安全委员会 (PSC) 已经发布了有关此漏洞的更多信息，详见此处。 GKE 集群可使用主授权网络和无公共端点的专用集群缓解此漏洞。该怎么做？我们建议您在包含修复方案的补丁程序版本发布后，尽快将集群升级到相应补丁程序版本。我们预计，它们将在 10 月 14 日那一周按计划发布的 GKE 版本中推出，届时将可供所有区域使用。下面列出了将包含缓解措施的补丁程序版本： 1.12.10-gke.15 1.13.11-gke.5 1.14.7-gke.10 1.15.4-gke.15 该补丁程序解决了哪些漏洞？该补丁程序缓解了以下漏洞： CVE-2019-11253 是一种拒绝服务攻击 (DoS) 漏洞。	高	CVE-2019-11253

说明

严重程度

备注

2019 年 10 月 24 日更新：经过修补的版本现已在所有区域推出。

近期在 Kubernetes 中发现了一个漏洞（如 CVE-2019-11253 中所述），该漏洞导致任何有权发出 POST 请求的用户都可以在 Kubernetes API 服务器上执行远程拒绝服务攻击。Kubernetes 产品安全委员会 (PSC) 已经发布了有关此漏洞的更多信息，详见此处。

GKE 集群可使用主授权网络和无公共端点的专用集群缓解此漏洞。

该怎么做？

我们建议您在包含修复方案的补丁程序版本发布后，尽快将集群升级到相应补丁程序版本。我们预计，它们将在 10 月 14 日那一周按计划发布的 GKE 版本中推出，届时将可供所有区域使用。

下面列出了将包含缓解措施的补丁程序版本：

1.12.10-gke.15
1.13.11-gke.5
1.14.7-gke.10
1.15.4-gke.15

该补丁程序解决了哪些漏洞？

该补丁程序缓解了以下漏洞：

CVE-2019-11253 是一种拒绝服务攻击 (DoS) 漏洞。

高

CVE-2019-11253

2019 年 9 月 16 日

发布日期：2019 年 9 月 16 日
更新日期：2019 年 10 月 16 日

说明	严重程度	备注
此公告在原始发布版本的基础上进行了更新。 Go 编程语言近期被发现存在新的安全漏洞 CVE-2019-9512 和 CVE-2019-9514，两者均属于拒绝服务攻击 (DoS) 漏洞。在 GKE 中，这些漏洞可能允许用户编写恶意请求，占用 Kubernetes API 服务器的大量 CPU 资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Go 编程语言披露信息。该怎么做？在包含针对此漏洞的缓解措施的最新补丁程序版本发布后，我们建议您尽快将集群升级到相应的补丁程序版本。根据发布时间表，我们预计这些补丁程序版本将随下个 GKE 版本一起在所有区域推出。下面列出了将包含缓解措施的补丁程序版本： 2019 年 10 月 16 日更新：1.12.10-gke.15 1.13.10-gke.0 1.14.6-gke.1 该补丁程序解决了哪一漏洞？该补丁程序缓解了以下漏洞： CVE-2019-9512 和 CVE-2019-9514 属于拒绝服务攻击 (DoS) 漏洞。	高	CVE-2019-9512 CVE-2019-9514

说明

严重程度

备注

此公告在原始发布版本的基础上进行了更新。

Go 编程语言近期被发现存在新的安全漏洞 CVE-2019-9512 和 CVE-2019-9514，两者均属于拒绝服务攻击 (DoS) 漏洞。在 GKE 中，这些漏洞可能允许用户编写恶意请求，占用 Kubernetes API 服务器的大量 CPU 资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Go 编程语言披露信息。

该怎么做？

在包含针对此漏洞的缓解措施的最新补丁程序版本发布后，我们建议您尽快将集群升级到相应的补丁程序版本。根据发布时间表，我们预计这些补丁程序版本将随下个 GKE 版本一起在所有区域推出。

下面列出了将包含缓解措施的补丁程序版本：

2019 年 10 月 16 日更新：1.12.10-gke.15
1.13.10-gke.0
1.14.6-gke.1

该补丁程序解决了哪一漏洞？

该补丁程序缓解了以下漏洞：

CVE-2019-9512 和 CVE-2019-9514 属于拒绝服务攻击 (DoS) 漏洞。

高

CVE-2019-9512
CVE-2019-9514

2019 年 9 月 5 日

发布日期：2019 年 9 月 5 日
更新日期：2019 年 9 月 5 日

修复 2019 年 5 月 31 日的安全公告内记录的漏洞的公告已更新。

2019 年 8 月 22 日

发布日期：2019 年 8 月 22 日
更新日期：2019 年 8 月 22 日

2019 年 8 月 5 日的公告已更新。先前发布的一则公告中记录的漏洞的修复已发布。

2019 年 8 月 8 日

发布日期：2019 年 8 月 8 日
更新日期：2019 年 8 月 8 日

2019 年 8 月 5 日的公告已更新。我们预计，该公告中记录的漏洞的修复将在下个版本的 GKE 中提供。

2019 年 8 月 5 日

发布日期：2019 年 8 月 5 日
更新日期：2019 年 8 月 9 日

说明	严重程度	备注
此公告在原始发布版本的基础上进行了更新。 Kubernetes 最近发现了一个漏洞 (CVE-2019-11247)，该漏洞允许集群级的自定义资源实例像存在于所有命名空间内的有命名空间对象一样得到处理。这意味着仅有命名空间级 RBAC 权限的用户和服务账号可以与集群级自定义资源交互。利用此漏洞要求攻击者具有访问任意命名空间内资源的权限。该怎么做？在包含此漏洞缓解措施的最新补丁程序版本发布后，建议您尽快将集群升级到该补丁程序版本。我们预计，它们将随下个 GKE 版本在所有区域提供。下面列出了将包含缓解措施的补丁程序版本： 1.11.10-gke.6 1.12.9-gke.13 1.13.7-gke.19 1.14.3-gke.10（快速版）该补丁程序解决了什么漏洞？该补丁程序缓解了以下漏洞：CVE-2019-11247。	中	CVE-2019-11247

说明

严重程度

备注

此公告在原始发布版本的基础上进行了更新。

Kubernetes 最近发现了一个漏洞 (CVE-2019-11247)，该漏洞允许集群级的自定义资源实例像存在于所有命名空间内的有命名空间对象一样得到处理。这意味着仅有命名空间级 RBAC 权限的用户和服务账号可以与集群级自定义资源交互。利用此漏洞要求攻击者具有访问任意命名空间内资源的权限。

该怎么做？

在包含此漏洞缓解措施的最新补丁程序版本发布后，建议您尽快将集群升级到该补丁程序版本。我们预计，它们将随下个 GKE 版本在所有区域提供。下面列出了将包含缓解措施的补丁程序版本：

1.11.10-gke.6
1.12.9-gke.13
1.13.7-gke.19
1.14.3-gke.10（快速版）

该补丁程序解决了什么漏洞？

该补丁程序缓解了以下漏洞：CVE-2019-11247。

中

CVE-2019-11247

2019 年 7 月 3 日

发布日期：2019 年 7 月 3 日
更新日期：2019 年 7 月 3 日

说明严重程度备注

说明	严重程度	备注
解决 CVE-2019-11246 的 `kubectl` 修补版本将随 `gcloud` 253.0.0 一起提供。如需了解详情，请参阅 2019 年 6 月 25 日的安全公告。注意：该补丁程序在 `kubectl` 1.11.10 中不可用。	高	CVE-2019-11246

解决 CVE-2019-11246 的 kubectl 修补版本将随 gcloud 253.0.0 一起提供。如需了解详情，请参阅 2019 年 6 月 25 日的安全公告。

注意：该补丁程序在 kubectl 1.11.10 中不可用。

高

CVE-2019-11246

2019 年 7 月 3 日

发布日期：2019 年 6 月 25 日
更新日期：2019 年 7 月 3 日

说明严重程度备注

说明	严重程度	备注
2019 年 7 月 3 日更新在我们上次更新此公告时，1.11.9 版和 1.11.10 版的补丁程序尚不可用。现在，我们已经发布了 1.11.10-gke.5，作为这两个 1.11 版本的升级目标。目前，GKE 主实例已得到修补，运行 Kubernetes Engine 的 Google 基础架构已得到修补，提供了抵御此漏洞的保护机制。 1.11 主实例将很快弃用，并计划于 2019 年 7 月 8 日这一周自动升级到 1.12 版本。您可以选择以下任意推荐操作，将节点升级到经过修补的版本。在 2019 年 7 月 8 日之前，将节点升级到 1.11.10-gke.5。在此日期之后，我们会开始将 1.11 版本从可用升级目标列表中移除。在 1.11 节点上启用自动升级，允许主实例升级到 1.12 时升级这些节点。执行手动升级，将主实例和这些节点升级到已修复的 1.12 版本。 2019 年 6 月 24 日发布的原始公告如下： 2019 年 6 月 24 日更新截至 2019 年 6 月 22 日 21:40（世界协调时间 (UTC)），我们提供了以下经过修补的 Kubernetes 版本。版本介于 Kubernetes 1.11.0 与 1.13.6 之间的主实例将自动更新到修补后的版本。如果您运行的版本不兼容此补丁程序，请先将主实例升级到兼容的版本（参见下方列表），然后再升级节点。由于这些漏洞的严重性，无论您是否启用了节点自动升级，我们都建议您尽快执行手动升级，将您的节点和主实例升级到下列版本之一。已修补的版本： 1.11.8-gke.10 1.12.7-gke.24 1.12.8-gke.10 1.13.6-gke.13 2019 年 6 月 18 日发布的原始公告如下： Netflix 近来披露了 Linux 内核中的三个 TCP 漏洞： CVE-2019-11477 CVE-2019-11478 CVE-2019-11479 这些 CVE 统称为 NFLX-2019-001。未经修补的 Linux 内核可能很容易受到远程触发的拒绝服务攻击。发送或接收不受信任的网络流量的 Google Kubernetes Engine 节点会受到影响，我们建议您按照下方的缓解步骤保护您的工作负载。 Kubernetes 主实例使用授权网络，将流量限制为与受信任网络之间的流量的 Kubernetes 主实例不受影响。由 Google 管理的 GKE 集群主实例将在未来几天内自动得到修补。客户无需采取任何行动。 Kubernetes 节点将流量限制为与受信任网络之间的流量的节点不受影响。符合以下条件的集群属于这种情形：通过防火墙禁止与不受信任的网络之间通信的节点，或者没有公共 IP 地址的节点（私有集群）没有公共 LoadBalancer 服务的集群 Google 正在准备这些漏洞的永久性缓解措施，并将作为新节点版本推出。在永久性修复措施可用后，我们将更新本公告，也会向所有 GKE 客户发送一封电子邮件。在永久性修复措施推出之前，我们创建了一个 Kubernetes DaemonSet，通过修改主机 `iptables` 配置实施缓解措施。该怎么做？请运行以下命令，在您的集群的所有节点上应用 Kubernetes DaemonSet。这会向节点上的现有 `iptables` 规则中添加一条 `iptables` 规则，缓解该漏洞。为每个 Google Cloud 项目的每个集群运行一次该命令。 kubectl apply -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml 由于 GKE 不支持 Ipv6，无需 ip6tables 规则。在经过修补的节点版本可用，并且您升级了所有可能受影响的节点之后，即可使用如下命令移除 DaemonSet。为每个 Google Cloud 项目的每个集群运行一次该命令。 kubectl delete -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml	高中中	CVE-2019-11477 CVE-2019-11478 CVE-2019-11479

2019 年 7 月 3 日更新

在我们上次更新此公告时，1.11.9 版和 1.11.10 版的补丁程序尚不可用。现在，我们已经发布了 1.11.10-gke.5，作为这两个 1.11 版本的升级目标。

目前，GKE 主实例已得到修补，运行 Kubernetes Engine 的 Google 基础架构已得到修补，提供了抵御此漏洞的保护机制。

1.11 主实例将很快弃用，并计划于 2019 年 7 月 8 日这一周自动升级到 1.12 版本。您可以选择以下任意推荐操作，将节点升级到经过修补的版本。

在 2019 年 7 月 8 日之前，将节点升级到 1.11.10-gke.5。在此日期之后，我们会开始将 1.11 版本从可用升级目标列表中移除。
在 1.11 节点上启用自动升级，允许主实例升级到 1.12 时升级这些节点。
执行手动升级，将主实例和这些节点升级到已修复的 1.12 版本。

2019 年 6 月 24 日发布的原始公告如下：

2019 年 6 月 24 日更新

截至 2019 年 6 月 22 日 21:40（世界协调时间 (UTC)），我们提供了以下经过修补的 Kubernetes 版本。版本介于 Kubernetes 1.11.0 与 1.13.6 之间的主实例将自动更新到修补后的版本。如果您运行的版本不兼容此补丁程序，请先将主实例升级到兼容的版本（参见下方列表），然后再升级节点。

由于这些漏洞的严重性，无论您是否启用了节点自动升级，我们都建议您尽快执行手动升级，将您的节点和主实例升级到下列版本之一。

已修补的版本：

1.11.8-gke.10
1.12.7-gke.24
1.12.8-gke.10
1.13.6-gke.13

2019 年 6 月 18 日发布的原始公告如下：

Netflix 近来披露了 Linux 内核中的三个 TCP 漏洞：

这些 CVE 统称为 NFLX-2019-001。

未经修补的 Linux 内核可能很容易受到远程触发的拒绝服务攻击。发送或接收不受信任的网络流量的 Google Kubernetes Engine 节点会受到影响，我们建议您按照下方的缓解步骤保护您的工作负载。

Kubernetes 主实例

使用授权网络，将流量限制为与受信任网络之间的流量的 Kubernetes 主实例不受影响。
由 Google 管理的 GKE 集群主实例将在未来几天内自动得到修补。客户无需采取任何行动。

Kubernetes 节点

将流量限制为与受信任网络之间的流量的节点不受影响。符合以下条件的集群属于这种情形：

通过防火墙禁止与不受信任的网络之间通信的节点，或者没有公共 IP 地址的节点（私有集群）
没有公共 LoadBalancer 服务的集群

Google 正在准备这些漏洞的永久性缓解措施，并将作为新节点版本推出。在永久性修复措施可用后，我们将更新本公告，也会向所有 GKE 客户发送一封电子邮件。

在永久性修复措施推出之前，我们创建了一个 Kubernetes DaemonSet，通过修改主机 iptables 配置实施缓解措施。

该怎么做？

请运行以下命令，在您的集群的所有节点上应用 Kubernetes DaemonSet。这会向节点上的现有 iptables 规则中添加一条 iptables 规则，缓解该漏洞。为每个 Google Cloud 项目的每个集群运行一次该命令。

kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

在经过修补的节点版本可用，并且您升级了所有可能受影响的节点之后，即可使用如下命令移除 DaemonSet。为每个 Google Cloud 项目的每个集群运行一次该命令。

kubectl delete -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

高
中
中

CVE-2019-11477
CVE-2019-11478
CVE-2019-11479

2019 年 6 月 25 日

说明严重程度备注

说明	严重程度	备注
2019 年 7 月 3 日更新：此补丁程序在 `gcloud` 253.0.0 中可用，适用于 `kubectl` 1.12.9、1.13.6、1.14.2 和更新版本。注意：该补丁程序在 1.11.10 中不可用。 Kubernetes 近期发现了一个漏洞 (CVE-2019-11246)，它允许具有容器内的 `kubectl cp` 操作和代码执行访问权限的攻击者修改主机上的文件。此漏洞可能允许攻击者在主机文件系统中替换或创建文件。如需了解详情，请参阅 Kubernetes 披露信息。所有 Google Kubernetes Engine (GKE) `gcloud` 版本都会受到此漏洞的影响，我们建议您在 `gcloud` 的最新补丁程序版本推出后升级到该补丁程序版本。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。该怎么做？在即将推出的 `gcloud` 版本中将提供经过修补的 `kubectl` 版本。您还可以自行直接升级 `kubectl`。在 `gcloud` 版本说明中可以跟踪此补丁程序的可用情况。该补丁程序解决了什么漏洞？ CVE-2019-11246 漏洞允许具有容器内的 `kubectl cp` 操作和代码执行访问权限的攻击者修改主机上的文件。此漏洞可能允许攻击者在主机文件系统中替换或创建文件	高	CVE-2019-11246

2019 年 7 月 3 日更新：此补丁程序在 gcloud 253.0.0 中可用，适用于 kubectl 1.12.9、1.13.6、1.14.2 和更新版本。

注意：该补丁程序在 1.11.10 中不可用。

Kubernetes 近期发现了一个漏洞 (CVE-2019-11246)，它允许具有容器内的 kubectl cp 操作和代码执行访问权限的攻击者修改主机上的文件。此漏洞可能允许攻击者在主机文件系统中替换或创建文件。如需了解详情，请参阅 Kubernetes 披露信息。

所有 Google Kubernetes Engine (GKE) gcloud 版本都会受到此漏洞的影响，我们建议您在 gcloud 的最新补丁程序版本推出后升级到该补丁程序版本。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。

该怎么做？

在即将推出的 gcloud 版本中将提供经过修补的 kubectl 版本。您还可以自行直接升级 kubectl。

在 gcloud 版本说明中可以跟踪此补丁程序的可用情况。

该补丁程序解决了什么漏洞？

CVE-2019-11246 漏洞允许具有容器内的 kubectl cp 操作和代码执行访问权限的攻击者修改主机上的文件。此漏洞可能允许攻击者在主机文件系统中替换或创建文件

高

CVE-2019-11246

2019 年 6 月 18 日

说明严重程度备注

说明	严重程度	备注
Docker 近期发现存在一个漏洞 (CVE-2018-15664)，它允许能够在容器内执行代码的攻击者劫持外部发起的 `docker cp` 操作。此漏洞可能允许攻击者将文件写入位置更改为主机文件系统中的任意位置。运行 Docker 的所有 Google Kubernetes Engine (GKE) 节点均受此漏洞影响，我们建议您在最新补丁程序版本推出后升级到该补丁程序版本。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。版本早于 1.12.7 的所有 Google Kubernetes Engine (GKE) 主实例都在运行 Docker，会受到此漏洞的影响。在 GKE 上，用户不具备主实例上 `docker cp` 的访问权限，因此该漏洞给 GKE 主实例造成的风险有限。该怎么做？只有在节点运行 Docker 并且发出有可能被劫持的 `docker cp`（或 API 等效）命令时，此类节点才会受到影响。我们预计，Kubernetes 环境满足这些条件的情况非常少见。运行带有 containerd 的 COS 的节点不受影响。如需升级节点，您必须首先将主实例升级为经过修补的版本。在补丁程序可用时，您可以发起主实例升级，也可以等待 Google 自动升级主实例。该补丁程序将在 Docker 18.09.7 中提供，并且会包含在即将发布的 GKE 补丁程序中。此补丁程序仅适用于 GKE 1.13 及更高版本。我们将按照常规升级节奏，自动将集群主实例升级到经过修补的版本。在经过修补的版本可用后，您也可以自行发起主实例升级。. 在包含补丁程序的版本可用后，我们将更新此公告。在版本说明中可以跟踪这些补丁程序的可用情况。该补丁程序解决了哪一漏洞？该补丁程序解决了以下漏洞：漏洞 CVE-2018-15664 允许能够在容器内执行代码的攻击者劫持外部发起的 `docker cp` 操作。此漏洞可能允许攻击者将文件写入位置更改为主机文件系统中的任意位置。	高

Docker 近期发现存在一个漏洞 (CVE-2018-15664)，它允许能够在容器内执行代码的攻击者劫持外部发起的 docker cp 操作。此漏洞可能允许攻击者将文件写入位置更改为主机文件系统中的任意位置。

运行 Docker 的所有 Google Kubernetes Engine (GKE) 节点均受此漏洞影响，我们建议您在最新补丁程序版本推出后升级到该补丁程序版本。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。

版本早于 1.12.7 的所有 Google Kubernetes Engine (GKE) 主实例都在运行 Docker，会受到此漏洞的影响。 在 GKE 上，用户不具备主实例上 docker cp 的访问权限，因此该漏洞给 GKE 主实例造成的风险有限。

该怎么做？

只有在节点运行 Docker 并且发出有可能被劫持的 docker cp（或 API 等效）命令时，此类节点才会受到影响。我们预计，Kubernetes 环境满足这些条件的情况非常少见。运行带有 containerd 的 COS 的节点不受影响。

如需升级节点，您必须首先将主实例升级为经过修补的版本。在补丁程序可用时，您可以发起主实例升级，也可以等待 Google 自动升级主实例。该补丁程序将在 Docker 18.09.7 中提供，并且会包含在即将发布的 GKE 补丁程序中。此补丁程序仅适用于 GKE 1.13 及更高版本。

我们将按照常规升级节奏，自动将集群主实例升级到经过修补的版本。在经过修补的版本可用后，您也可以自行发起主实例升级。.

在包含补丁程序的版本可用后，我们将更新此公告。在版本说明中可以跟踪这些补丁程序的可用情况。

该补丁程序解决了哪一漏洞？

该补丁程序解决了以下漏洞：

漏洞 CVE-2018-15664 允许能够在容器内执行代码的攻击者劫持外部发起的 docker cp 操作。此漏洞可能允许攻击者将文件写入位置更改为主机文件系统中的任意位置。

高

2019 年 5 月 31 日

说明严重程度备注

说明	严重程度	备注
此公告在原始发布版本的基础上进行了更新。 2019 年 8 月 2 日更新在初始公告发布时，仅有 1.13.6-gke.0 到 1.13.6-gke.5 受影响。由于回归，目前所有 1.13.6.x 版本均受影响。如果您目前在运行 1.13.6 版本，请尽快升级到 1.13.7。 Kubernetes 项目披露，kubelet v1.13.6 和 v1.14.2 中存在漏洞 CVE-2019-11245，这可能导致容器以 UID 0（通常映射到 `root` 用户）的身份运行，即便容器映像中指定了不同用户也是如此。如果您以非根用户的身份运行容器，而且您运行的节点版本是 1.13.6-gke.0 至 1.13.6-gke.6，我们建议您在不应以 UID 0 的身份运行容器的集群的所有 Pod 上设置 `RunAsUser`。如果指定了非根用户 `USER` 值（例如，通过在 Dockerfile 中设置 `USER` 值），则可能发生意外行为。容器首次在一个节点上运行时会正确采用指定 UID。但由于此缺陷的存在，在第二次（及后续）运行的时候，无论指定 UID 如何，该容器都会以 UID 0 的身份运行。这通常属于不希望发生的权限升级，可能导致意外的应用行为。如何判断我运行的版本是否受影响？请运行以下命令，列出所有节点及其 kubelet 版本： kubectl get nodes -o=jsonpath='{range .items[*]}'\ '{.status.nodeInfo.machineID}'\ '{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}' 如果输出列出了如下 kubelet 版本，则您的节点受此问题影响： v1.13.6 v1.14.2 如何判断我的特定配置是否受影响？如果您以非根用户的身份运行容器，而且您运行的节点版本是 1.13.6-gke.0 至 1.13.6-gke.6，则除以下情况外，您都会受到影响：为 `runAsUser` PodSecurityContext 指定有效非根用户值的 Pod 不受影响，并且能继续按预期运行。强制实施 `runAsUser` 设置的 PodSecurityPolicy 也不受影响，能够继续按预期运行。指定了 `mustRunAsNonRoot:true` 的 Pod 不会以 UID 0 的身份启动，但在受此问题影响时无法正常启动。该怎么做？在集群中不应以 UID 0 身份运行的所有 Pod 上设置 RunAsUser 安全上下文。您可以使用 PodSecurityPolicy 应用此配置。	中	CVE-2019-11245

此公告在原始发布版本的基础上进行了更新。

2019 年 8 月 2 日更新

在初始公告发布时，仅有 1.13.6-gke.0 到 1.13.6-gke.5 受影响。由于回归，目前所有 1.13.6.x 版本均受影响。如果您目前在运行 1.13.6 版本，请尽快升级到 1.13.7。

Kubernetes 项目披露，kubelet v1.13.6 和 v1.14.2 中存在漏洞 CVE-2019-11245，这可能导致容器以 UID 0（通常映射到 root 用户）的身份运行，即便容器映像中指定了不同用户也是如此。如果您以非根用户的身份运行容器，而且您运行的节点版本是 1.13.6-gke.0 至 1.13.6-gke.6，我们建议您在不应以 UID 0 的身份运行容器的集群的所有 Pod 上设置 RunAsUser。

如果指定了非根用户 USER 值（例如，通过在 Dockerfile 中设置 USER 值），则可能发生意外行为。容器首次在一个节点上运行时会正确采用指定 UID。但由于此缺陷的存在，在第二次（及后续）运行的时候，无论指定 UID 如何，该容器都会以 UID 0 的身份运行。这通常属于不希望发生的权限升级，可能导致意外的应用行为。

如何判断我运行的版本是否受影响？

请运行以下命令，列出所有节点及其 kubelet 版本：

kubectl get nodes -o=jsonpath='{range .items[*]}'\
'{.status.nodeInfo.machineID}'\
'{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

如果输出列出了如下 kubelet 版本，则您的节点受此问题影响：

v1.13.6
v1.14.2

如何判断我的特定配置是否受影响？

如果您以非根用户的身份运行容器，而且您运行的节点版本是 1.13.6-gke.0 至 1.13.6-gke.6，则除以下情况外，您都会受到影响：

为 runAsUser PodSecurityContext 指定有效非根用户值的 Pod 不受影响，并且能继续按预期运行。
强制实施 runAsUser 设置的 PodSecurityPolicy 也不受影响，能够继续按预期运行。
指定了 mustRunAsNonRoot:true 的 Pod 不会以 UID 0 的身份启动，但在受此问题影响时无法正常启动。

该怎么做？

在集群中不应以 UID 0 身份运行的所有 Pod 上设置 RunAsUser 安全上下文。您可以使用 PodSecurityPolicy 应用此配置。

中

CVE-2019-11245

2019 年 5 月 14 日

说明严重程度备注

说明	严重程度	备注
2019 年 6 月 11 日更新：2019 年 5 月 28 日那一周中发布的 1.11.10-gke.4、1.12.8-gke.6 和 1.13.6-gke.5 及更新的版本中提供了该补丁程序。 Intel 披露了以下 CVE： CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091 这些 CVE 统称为微架构数据抽样 (MDS)。这些漏洞可用于通过推测性执行技术与微架构状态交互，从而造成数据泄露风险。如需了解详情，请参阅 Intel 披露信息。运行 Kubernetes Engine 的主机基础架构将客户的工作负载彼此隔离。除非您在自己的多租户 GKE 集群内部运行不受信任的代码，否则不会受此问题影响。如果用户在 Kubernetes Engine 内部其自己的多租户服务中运行不受信任的代码，则该漏洞可能产生极为严重的影响。如需在 Kubernetes Engine 内缓解此漏洞，请在您的节点内禁用超线程。这些漏洞仅影响使用多个 CPU 的 Google Kubernetes Engine (GKE) 节点。请注意，n1-standard-1（GKE 默认设置）、g1-small 和 f1-micro 虚拟机仅会向客机环境公开 1 个 vCPU，因此无需禁用超线程。即将发布的补丁程序版本中将包含启用强制刷新功能的附加保护机制。我们将在未来几周内按常规升级节奏将启用自动升级的主实例和节点自动升级到修补后的版本。不过仅凭补丁程序本身不足以缓解此漏洞的风险。请参见下文了解推荐措施。如果您在运行 GKE On-Prem，则根据所用硬件，您可能会受此漏洞影响。请参阅 Intel 披露信息。该怎么做？除非您在自己的多租户 GKE 集群内运行不受信任的代码，否则不会受到影响。对于 Kubernetes Engine 内的节点，请创建停用了超线程的新节点池，并重新将您的工作负载安排到新节点上。请注意，n1-standard-1、g1-small 和 f1-micro 虚拟机仅向客机环境公开 1 个 vCPU，因此不需要停用超线程。警告：停用超线程可能会对您的集群和应用产生严重性能影响。请在将此项举措部署到您的生产集群之前，确保可以接受这种影响。可以通过部署 DaemonSet 在 GKE 节点池级别上停用超线程。但部署此 DaemonSet 将导致您在该节点池中的所有节点同时重新启动。因此，建议在您的集群内创建新节点池，部署 DaemonSet 以在该节点池内停用超线程，随后将工作负载迁移到新节点池。创建停用了超线程的新节点池的方法如下：在集群中使用节点标签 `cloud.google.com/gke-smt-disabled=true` 创建一个新的节点池： gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \ --node-labels=cloud.google.com/gke-smt-disabled=true 将 DaemonSet 部署到这个新节点池。DaemonSet 只会在带有 `cloud.google.com/gke-smt-disabled=true` 标签的节点上运行。它将停用超线程，然后重新启动节点。 kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/\ k8s-node-tools/master/disable-smt/gke/disable-smt.yaml 确保 DaemonSet Pod 处于运行状态。 kubectl get pods --selector=name=disable-smt -n kube-system 您应该会收到类似如下的响应： NAME READY STATUS RESTARTS AGE disable-smt-2xnnc 1/1 Running 0 6m 检查 pod 的日志中是否出现“SMT 已停用”(SMT has been disabled)。 kubectl logs disable-smt-2xnnc disable-smt -n kube-system 注意：如果节点启用了安全启动功能，则启动选项无法修改。如果安全启动功能已经启用，需要首先将其停用，然后才能创建 DaemonSet。您必须让 DaemonSet 在节点池上保持运行，从而使得池中创建的新节点可以自动应用更改。节点创建可由节点自动修复、手动升级或自动升级和自动扩缩触发。如需再次启用超线程，您需要重新创建节点池，但不要在其中部署所提供的 DaemonSet，然后将工作负载迁移到新节点池。我们还建议您在补丁程序可用后手动升级节点。若要升级，您必须先将主实例升级到最新版本。GKE 主实例会按照常规升级节奏自动升级。在包含补丁程序的版本发布后，我们将更新此公告。该补丁程序解决了哪一漏洞？该补丁程序缓解了以下漏洞： CVE-2018-12126、CVE-2018-12127、CVE-2018-12130、CVE-2019-11091：这些漏洞会利用推测性执行技术发起攻击。这些 CVE 统称为微架构数据抽样。这些漏洞可用于通过推测性执行技术与微架构状态交互，从而造成数据泄露风险。	中	CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2018-11091

2019 年 6 月 11 日更新：2019 年 5 月 28 日那一周中发布的 1.11.10-gke.4、1.12.8-gke.6 和 1.13.6-gke.5 及更新的版本中提供了该补丁程序。

Intel 披露了以下 CVE：

这些 CVE 统称为微架构数据抽样 (MDS)。这些漏洞可用于通过推测性执行技术与微架构状态交互，从而造成数据泄露风险。如需了解详情，请参阅 Intel 披露信息。

运行 Kubernetes Engine 的主机基础架构将客户的工作负载彼此隔离。除非您在自己的多租户 GKE 集群内部运行不受信任的代码，否则不会受此问题影响。

如果用户在 Kubernetes Engine 内部其自己的多租户服务中运行不受信任的代码，则该漏洞可能产生极为严重的影响。如需在 Kubernetes Engine 内缓解此漏洞，请在您的节点内禁用超线程。这些漏洞仅影响使用多个 CPU 的 Google Kubernetes Engine (GKE) 节点。请注意，n1-standard-1（GKE 默认设置）、g1-small 和 f1-micro 虚拟机仅会向客机环境公开 1 个 vCPU，因此无需禁用超线程。

即将发布的补丁程序版本中将包含启用强制刷新功能的附加保护机制。我们将在未来几周内按常规升级节奏将启用自动升级的主实例和节点自动升级到修补后的版本。不过仅凭补丁程序本身不足以缓解此漏洞的风险。请参见下文了解推荐措施。

如果您在运行 GKE On-Prem，则根据所用硬件，您可能会受此漏洞影响。请参阅 Intel 披露信息。

该怎么做？

除非您在自己的多租户 GKE 集群内运行不受信任的代码，否则不会受到影响。

对于 Kubernetes Engine 内的节点，请创建停用了超线程的新节点池，并重新将您的工作负载安排到新节点上。

请注意，n1-standard-1、g1-small 和 f1-micro 虚拟机仅向客机环境公开 1 个 vCPU，因此不需要停用超线程。

警告：

停用超线程可能会对您的集群和应用产生严重性能影响。请在将此项举措部署到您的生产集群之前，确保可以接受这种影响。
可以通过部署 DaemonSet 在 GKE 节点池级别上停用超线程。但部署此 DaemonSet 将导致您在该节点池中的所有节点同时重新启动。因此，建议在您的集群内创建新节点池，部署 DaemonSet 以在该节点池内停用超线程，随后将工作负载迁移到新节点池。

创建停用了超线程的新节点池的方法如下：

在集群中使用节点标签 cloud.google.com/gke-smt-disabled=true 创建一个新的节点池：

gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true

将 DaemonSet 部署到这个新节点池。DaemonSet 只会在带有 cloud.google.com/gke-smt-disabled=true 标签的节点上运行。它将停用超线程，然后重新启动节点。
```
kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
```

确保 DaemonSet Pod 处于运行状态。

kubectl get pods --selector=name=disable-smt -n kube-system

您应该会收到类似如下的响应：

NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m

检查 pod 的日志中是否出现“SMT 已停用”(SMT has been disabled)。
```
kubectl logs disable-smt-2xnnc disable-smt -n kube-system
```

您必须让 DaemonSet 在节点池上保持运行，从而使得池中创建的新节点可以自动应用更改。节点创建可由节点自动修复、手动升级或自动升级和自动扩缩触发。

如需再次启用超线程，您需要重新创建节点池，但不要在其中部署所提供的 DaemonSet，然后将工作负载迁移到新节点池。

我们还建议您在补丁程序可用后手动升级节点。若要升级，您必须先将主实例升级到最新版本。GKE 主实例会按照常规升级节奏自动升级。

在包含补丁程序的版本发布后，我们将更新此公告。

该补丁程序解决了哪一漏洞？

该补丁程序缓解了以下漏洞：

CVE-2018-12126、CVE-2018-12127、CVE-2018-12130、CVE-2019-11091：这些漏洞会利用推测性执行技术发起攻击。这些 CVE 统称为微架构数据抽样。这些漏洞可用于通过推测性执行技术与微架构状态交互，从而造成数据泄露风险。

中

2019 年 4 月 5 日

说明	严重程度	备注
近期发现了 CVE-2019-9900 和 CVE-2019-9901 这两个 Envoy 漏洞。 Envoy 嵌入在 Istio 之中，这些漏洞允许用户在某些情况下绕过 Istio 政策。如果您在 Google Kubernetes Engine (GKE) 上启用了 Istio，那么就可能会受到这些漏洞的影响。在最新补丁程序版本发布后，我们建议您尽快将受影响的集群升级到这些补丁程序版本，并且升级您的 Istio Sidecar（请参见下方说明）。该怎么做？鉴于这些漏洞的严重级别，无论您是否启用了节点自动升级，我们都建议您采取以下措施：在补丁程序可用时立即手动升级您的集群。按照 Sidecar 升级文档升级您的 Sidecar。修补后的版本将在今天下午 7:00（美国太平洋夏令时间）之前推出，可供所有 GKE 项目使用。以下 GKE 版本将提供此补丁程序。在 GKE 安全公告页面上发布相应信息之后（预计在 2019 年 4 月 15 日发布），新集群将默认使用修补后的版本，如果您在此之前创建了新集群，则必须为您的集群指定使用修补后的版本。启用了节点自动升级的 GKE 客户以及未手动升级的 GKE 客户，其节点会在此后一周内自动升级到修补后的版本。修补后的版本： 1.10.12-gke.14 1.11.6-gke.16 1.11.7-gke.18 1.11.8-gke.6 1.12.6-gke.10 1.13.4-gke.10 该补丁程序解决了哪一漏洞？该补丁程序缓解了以下漏洞： CVE-2019-9900 和 CVE-2019-9901。您可以访问 Istio 博客详细了解相关信息。	高	CVE-2019-9900 CVE-2019-9901。

说明

严重程度

备注

近期发现了 CVE-2019-9900 和 CVE-2019-9901 这两个 Envoy 漏洞。

Envoy 嵌入在 Istio 之中，这些漏洞允许用户在某些情况下绕过 Istio 政策。

如果您在 Google Kubernetes Engine (GKE) 上启用了 Istio，那么就可能会受到这些漏洞的影响。在最新补丁程序版本发布后，我们建议您尽快将受影响的集群升级到这些补丁程序版本，并且升级您的 Istio Sidecar（请参见下方说明）。

该怎么做？

鉴于这些漏洞的严重级别，无论您是否启用了节点自动升级，我们都建议您采取以下措施：

在补丁程序可用时立即手动升级您的集群。
按照 Sidecar 升级文档升级您的 Sidecar。

修补后的版本将在今天下午 7:00（美国太平洋夏令时间）之前推出，可供所有 GKE 项目使用。

以下 GKE 版本将提供此补丁程序。在 GKE 安全公告页面上发布相应信息之后（预计在 2019 年 4 月 15 日发布），新集群将默认使用修补后的版本，如果您在此之前创建了新集群，则必须为您的集群指定使用修补后的版本。启用了节点自动升级的 GKE 客户以及未手动升级的 GKE 客户，其节点会在此后一周内自动升级到修补后的版本。

修补后的版本：

1.10.12-gke.14
1.11.6-gke.16
1.11.7-gke.18
1.11.8-gke.6
1.12.6-gke.10
1.13.4-gke.10

该补丁程序解决了哪一漏洞？

该补丁程序缓解了以下漏洞：

CVE-2019-9900 和 CVE-2019-9901。您可以访问 Istio 博客详细了解相关信息。

高

CVE-2019-9900
CVE-2019-9901。

2019 年 3 月 1 日

说明	严重程度	备注
2019 年 3 月 22 日更新：此补丁程序将在 Kubernetes 1.11.8-gke.4、1.13.4-gke.1 和更新版本中可用。此补丁程序在 1.12 版本中尚不可用。在版本说明中可以跟踪这些补丁程序的可用情况。 Kubernetes 近来发现了一个新的拒绝服务攻击漏洞 CVE-2019-1002100，该漏洞允许获得发布补丁程序请求授权的用户编写恶意的 "json-patch" 请求，占用 Kubernetes API 服务器的大量 CPU 和内存资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Kubernetes 披露信息。所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。我们将在未来几周内按常规升级节奏将集群主实例自动升级到修补后的版本。该怎么做？您无需采取任何行动。GKE 主实例会按照常规升级节奏自动升级。如果您想尽快升级主实例，可以手动启动主实例升级。我们将更新本公告，列举包含补丁程序的版本。请注意，补丁程序仅可用于 1.11 及以上版本，不可用于 1.10 版本。该补丁程序解决了哪一漏洞？该补丁程序解决了以下漏洞： CVE-2019-1002100 漏洞允许用户编写“json-patch”类型的补丁程序，过量占用 Kubernetes API 服务器的 CPU 资源，有可能降低集群控制层面的可用性。	中	CVE-2019-1002100

说明

严重程度

备注

2019 年 3 月 22 日更新：此补丁程序将在 Kubernetes 1.11.8-gke.4、1.13.4-gke.1 和更新版本中可用。此补丁程序在 1.12 版本中尚不可用。在版本说明中可以跟踪这些补丁程序的可用情况。

Kubernetes 近来发现了一个新的拒绝服务攻击漏洞 CVE-2019-1002100，该漏洞允许获得发布补丁程序请求授权的用户编写恶意的 "json-patch" 请求，占用 Kubernetes API 服务器的大量 CPU 和内存资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Kubernetes 披露信息。所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响。即将推出的补丁程序版本将包含针对此漏洞的缓解措施。我们将在未来几周内按常规升级节奏将集群主实例自动升级到修补后的版本。

该怎么做？

您无需采取任何行动。GKE 主实例会按照常规升级节奏自动升级。如果您想尽快升级主实例，可以手动启动主实例升级。

我们将更新本公告，列举包含补丁程序的版本。请注意，补丁程序仅可用于 1.11 及以上版本，不可用于 1.10 版本。

该补丁程序解决了哪一漏洞？

该补丁程序解决了以下漏洞：

CVE-2019-1002100 漏洞允许用户编写“json-patch”类型的补丁程序，过量占用 Kubernetes API 服务器的 CPU 资源，有可能降低集群控制层面的可用性。

中

CVE-2019-1002100

2019 年 2 月 11 日 (runc)

说明	严重程度	备注
Open Containers Initiative (OCI) 近期发现了 runc 中的一个新安全漏洞 CVE-2019-5736，该漏洞允许容器逃逸，从而获得主机节点上的 root 权限。您的 Google Kubernetes Engine (GKE) Ubuntu 节点会受到这些漏洞的影响，我们建议您尽快升级到最新的补丁程序版本，具体说明如下所述。我该怎么做？若要升级节点，您必须先将主节点升级到最新版本。Kubernetes 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5 及更新的版本中提供了该补丁程序。在版本说明中可以跟踪这些补丁程序的可用情况。请注意，仅有 GKE 中的 Ubuntu 节点会受此影响。运行 COS 的节点不受影响。请注意，新版本的 runc 内存使用量更高，如果您先前设置了较低的内存限制 (< 16MB)，则可能需要更新分配给容器的内存量。该补丁程序解决了哪一漏洞？该补丁程序解决了以下漏洞： CVE-2019-5736 描述了 runc 中的一个漏洞，该漏洞允许恶意容器（只需极少的用户互动，执行一次 exec 即可触发）覆盖主机 runc 二进制文件，从而获得主机节点上的 root 级代码执行权限。未以 root 权限运行的容器不受影响。此漏洞的严重级别分级为“高”。	高	CVE-2019-5736

说明

严重程度

备注

Open Containers Initiative (OCI) 近期发现了 runc 中的一个新安全漏洞 CVE-2019-5736，该漏洞允许容器逃逸，从而获得主机节点上的 root 权限。

您的 Google Kubernetes Engine (GKE) Ubuntu 节点会受到这些漏洞的影响，我们建议您尽快升级到最新的补丁程序版本，具体说明如下所述。

我该怎么做？

若要升级节点，您必须先将主节点升级到最新版本。Kubernetes 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5 及更新的版本中提供了该补丁程序。在版本说明中可以跟踪这些补丁程序的可用情况。

请注意，仅有 GKE 中的 Ubuntu 节点会受此影响。运行 COS 的节点不受影响。

请注意，新版本的 runc 内存使用量更高，如果您先前设置了较低的内存限制 (< 16MB)，则可能需要更新分配给容器的内存量。

该补丁程序解决了哪一漏洞？

该补丁程序解决了以下漏洞：

CVE-2019-5736 描述了 runc 中的一个漏洞，该漏洞允许恶意容器（只需极少的用户互动，执行一次 exec 即可触发）覆盖主机 runc 二进制文件，从而获得主机节点上的 root 级代码执行权限。未以 root 权限运行的容器不受影响。此漏洞的严重级别分级为“高”。

高

CVE-2019-5736

2019 年 2 月 11 日 (Go)

说明	严重程度	备注
2019 年 2 月 25 日更新：与之前所宣布的一样，该补丁程序在 1.11.7-gke.4 中不可用。如果您运行的是 1.11.7，则可以采取这样的做法：降级到 1.11.6，再升级到 1.12，或者等到 2019 年 3 月 4 日那一周发布的下一个 1.11.7 补丁程序。 Go 编程语言近期被发现存在一个新的安全漏洞 CVE-2019-6486，这是 P-521 和 P-384 椭圆曲线的加密/椭圆实现中存在的一个拒绝服务攻击 (DoS) 漏洞。在 Google Kubernetes Engine (GKE) 中，该漏洞可能允许用户编写恶意请求，占用 Kubernetes API 服务器的大量 CPU 资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Go 编程语言披露信息。所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响。最新版本的补丁程序包含针对此漏洞的缓解措施。我们将在未来几周内按常规升级节奏将集群主实例自动升级到修补后的版本。该怎么做？您无需采取任何行动。GKE 主实例会按照常规升级节奏自动升级。如果您想尽快升级主实例，可以手动启动主实例升级。 GKE 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5 及更新的版本中提供了此补丁程序。该补丁程序解决了哪一漏洞？该补丁程序解决了以下漏洞： CVE-2019-6486 是 P-521 和 P-384 椭圆曲线的加密/椭圆实现中存在的一个漏洞。用户可以利用该漏洞编写输入，耗用大量 CPU 资源。	高	CVE-2019-6486

说明

严重程度

备注

2019 年 2 月 25 日更新：与之前所宣布的一样，该补丁程序在 1.11.7-gke.4 中不可用。如果您运行的是 1.11.7，则可以采取这样的做法：降级到 1.11.6，再升级到 1.12，或者等到 2019 年 3 月 4 日那一周发布的下一个 1.11.7 补丁程序。

Go 编程语言近期被发现存在一个新的安全漏洞 CVE-2019-6486，这是 P-521 和 P-384 椭圆曲线的加密/椭圆实现中存在的一个拒绝服务攻击 (DoS) 漏洞。在 Google Kubernetes Engine (GKE) 中，该漏洞可能允许用户编写恶意请求，占用 Kubernetes API 服务器的大量 CPU 资源，有可能降低集群控制平面的可用性。如需了解详情，请参阅 Go 编程语言披露信息。

所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响。最新版本的补丁程序包含针对此漏洞的缓解措施。我们将在未来几周内按常规升级节奏将集群主实例自动升级到修补后的版本。

该怎么做？

您无需采取任何行动。GKE 主实例会按照常规升级节奏自动升级。如果您想尽快升级主实例，可以手动启动主实例升级。

GKE 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5 及更新的版本中提供了此补丁程序。

该补丁程序解决了哪一漏洞？

该补丁程序解决了以下漏洞：

CVE-2019-6486 是 P-521 和 P-384 椭圆曲线的加密/椭圆实现中存在的一个漏洞。用户可以利用该漏洞编写输入，耗用大量 CPU 资源。

高

CVE-2019-6486

2018 年 12 月 3 日

说明	严重程度	备注
Kubernetes 最近发现了 CVE-2018-1002105 这个新的安全漏洞，该漏洞能让权限相对较低的用户绕过对 kubelet 的 API 的授权，使其能对集群中任何节点上的任何 Pod 执行任意操作。如需了解详情，请参阅 Kubernetes 披露信息。所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响，我们已经将集群升级到了最新补丁版本。您无需采取任何操作。该怎么做？您无需采取任何操作。GKE 主实例已升级。 GKE 1.9.7-gke.11、1.10.6-gke.11、1.10.7-gke.11、1.10.9-gke.5 和 1.11.2-gke.18 及更新的版本中提供了该补丁程序。该补丁程序解决了哪一漏洞？该补丁程序解决了以下漏洞： CVE-2018-1002105 漏洞能让权限相对较低的用户绕过对 kubelet 的 API 的授权。这使得用户可以获得授权，提出可升级的请求，从而实现提权并任意调用 kubelet 的 API。此漏洞在 Kubernetes 中的严重程度为“严重”。考虑到 GKE 实现中的一些细节会阻止未通过身份验证的提权路径，此漏洞在 GKE 中的严重程度为“高”。	高	CVE-2018-1002105

说明

严重程度

备注

Kubernetes 最近发现了 CVE-2018-1002105 这个新的安全漏洞，该漏洞能让权限相对较低的用户绕过对 kubelet 的 API 的授权，使其能对集群中任何节点上的任何 Pod 执行任意操作。如需了解详情，请参阅 Kubernetes 披露信息。所有 Google Kubernetes Engine (GKE) 主实例都会受到这些漏洞的影响，我们已经将集群升级到了最新补丁版本。您无需采取任何操作。

该怎么做？

您无需采取任何操作。GKE 主实例已升级。

GKE 1.9.7-gke.11、1.10.6-gke.11、1.10.7-gke.11、1.10.9-gke.5 和 1.11.2-gke.18 及更新的版本中提供了该补丁程序。

该补丁程序解决了哪一漏洞？

该补丁程序解决了以下漏洞：

CVE-2018-1002105 漏洞能让权限相对较低的用户绕过对 kubelet 的 API 的授权。这使得用户可以获得授权，提出可升级的请求，从而实现提权并任意调用 kubelet 的 API。此漏洞在 Kubernetes 中的严重程度为“严重”。考虑到 GKE 实现中的一些细节会阻止未通过身份验证的提权路径，此漏洞在 GKE 中的严重程度为“高”。

高

CVE-2018-1002105

2018 年 11 月 13 日

说明
2018 年 11 月 16 日更新：已完成所有可能受影响的令牌的吊销和轮替。您无需采取进一步行动。 Google 最近在 Calico Container Network Interface (CNI) 插件中发现了一个问题，该插件在某些配置下可以记录敏感信息。此问题由 Tigera 技术公告 TTA-2018-001 追踪记录。如果在运行时使用调试级日志记录选项，Calico CNI 插件会将 Kubernetes API 客户端配置写入日志。如果在 CNI 网络配置中设置了“k8s_auth_token”字段，Calico CNI 还会将 Kubernetes API 令牌写入信息级日志。此外，在使用调试级日志记录选项来运行该插件时，如果明确设置了服务账号令牌（无论是在 Calico 读取的 Calico 配置文件中设置，还是设置为 Calico 使用的环境变量），Calico 组件（calico/节点、felix、CNI）均会将此信息写入日志文件。这些令牌拥有以下权限：

说明

2018 年 11 月 16 日更新：已完成所有可能受影响的令牌的吊销和轮替。您无需采取进一步行动。

Google 最近在 Calico Container Network Interface (CNI) 插件中发现了一个问题，该插件在某些配置下可以记录敏感信息。此问题由 Tigera 技术公告 TTA-2018-001 追踪记录。

如果在运行时使用调试级日志记录选项，Calico CNI 插件会将 Kubernetes API 客户端配置写入日志。
如果在 CNI 网络配置中设置了“k8s_auth_token”字段，Calico CNI 还会将 Kubernetes API 令牌写入信息级日志。
此外，在使用调试级日志记录选项来运行该插件时，如果明确设置了服务账号令牌（无论是在 Calico 读取的 Calico 配置文件中设置，还是设置为 Calico 使用的环境变量），Calico 组件（calico/节点、felix、CNI）均会将此信息写入日志文件。

这些令牌拥有以下权限：

bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]

启用了集群网络政策和 Stackdriver Logging 的 Google Kubernetes Engine 集群会将 Calico 服务账号令牌记录到 Stackdriver 中。未启用网络政策的集群不受影响。

我们已部署一个修复程序，将 Calico CNI 插件改为仅记录警告级日志并使用新的服务账号。Calico 的修补代码将在之后的版本中部署。

下周，我们将对任何可能受到影响的令牌进行滚动吊销。吊销完成后，我们会更新此公告。您无需采取任何进一步行动。 （此轮替已于 2018 年 11 月 16 日完成）

如果您希望立即轮替这些令牌，则可运行以下命令，系统将在几秒钟内自动重新创建服务账号的新密钥：

kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system

检测

GKE 会记录所有访问 API 服务器的行为。如要确定是否有人在 Google Cloud 的预期 IP 范围之外使用了 Calico 令牌，您可以运行以下 Stackdriver 查询。请注意，这只会返回从 GCP 网络之外进行的调用的记录。您应该根据您的具体环境，按需要对查询进行自定义。

resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")

2018 年 8 月 14 日

说明	严重程度	备注
Intel 披露了以下 CVE： CVE-2018-3615（针对 SGX） CVE-2018-3620（针对操作系统和 SMT） CVE-2018-3646（针对虚拟化）这些 CVE 统称为“L1 终端故障 (L1TF)”。这些 L1TF 漏洞通过攻击处理器层的数据结构配置来利用推测性执行技术。 “L1”是指 1 级数据缓存 (L1D)，这是一种用于加快内存访问速度的小型芯片上资源。如需详细了解这些漏洞和 Compute Engine 的缓解措施，请参阅 Google Cloud 博文。对 Google Kubernetes Engine 的影响运行 Kubernetes Engine 并将客户的集群和节点彼此隔离的基础架构可以抵御已知攻击。使用 Google 的 Container-Optimized OS 映像且启用了自动升级的 Kubernetes Engine 节点池将在 COS 映像的修复版本可用时自动进行更新（修复版本自 2018 年 8 月 20 日那周起可用）。未启用自动升级的 Kubernetes Engine 节点池必须在 COS 映像的修补版本可用时手动进行更新。	高	CVE-2018-3615 CVE-2018-3620 CVE-2018-3646

说明

严重程度

备注

Intel 披露了以下 CVE：

CVE-2018-3615（针对 SGX）
CVE-2018-3620（针对操作系统和 SMT）
CVE-2018-3646（针对虚拟化）

这些 CVE 统称为“L1 终端故障 (L1TF)”。

这些 L1TF 漏洞通过攻击处理器层的数据结构配置来利用推测性执行技术。 “L1”是指 1 级数据缓存 (L1D)，这是一种用于加快内存访问速度的小型芯片上资源。

如需详细了解这些漏洞和 Compute Engine 的缓解措施，请参阅 Google Cloud 博文。

对 Google Kubernetes Engine 的影响

运行 Kubernetes Engine 并将客户的集群和节点彼此隔离的基础架构可以抵御已知攻击。

使用 Google 的 Container-Optimized OS 映像且启用了自动升级的 Kubernetes Engine 节点池将在 COS 映像的修复版本可用时自动进行更新（修复版本自 2018 年 8 月 20 日那周起可用）。

未启用自动升级的 Kubernetes Engine 节点池必须在 COS 映像的修补版本可用时手动进行更新。

高

2018 年 8 月 6 日；最后更新时间：2018 年 9 月 5 日

说明	严重程度	备注
2018 年 9 月 5 日更新 CVE-2018-5391 已于最近披露。与 CVE-2018-5390 一样，这也是一个内核级的网络漏洞，可提高拒绝服务攻击 (DoS) 对存在该漏洞的系统的破坏效力。两者的主要区别在于 CVE-2018-5391 可通过 IP 连接加以利用。为涵盖这两个漏洞，我们更新了此公告。说明 CVE-2018-5390（“SegmentSmack”）描述了一个内核级的网络漏洞，它可提高经由 TCP 连接的 DoS（拒绝服务）攻击对存在该漏洞的系统的破坏效力。 CVE-2018-5391（“FragmentSmack”）描述了一个内核级的网络漏洞，它可提高经由 IP 连接的 DoS（拒绝服务）攻击对存在该漏洞的系统的破坏效力。对 Google Kubernetes Engine 的影响截至 2018 年 8 月 11 日，所有 Kubernetes Engine 主节点都可以抵御对这两个漏洞的攻击。此外，所有配置为自动升级的 Kubernetes Engine 集群也可以抵御这类攻击。未配置为自动升级且最后一次手动升级是在 2018 年 8 月 11 日之前的 Kubernetes Engine 节点池会受到这两个漏洞的影响。修补版本鉴于此漏洞的严重级别，我们建议您在补丁程序可用时立即手动升级您的节点。	高	CVE-2018-5390 CVE-2018-5391

说明

严重程度

备注

2018 年 9 月 5 日更新

CVE-2018-5391 已于最近披露。与 CVE-2018-5390 一样，这也是一个内核级的网络漏洞，可提高拒绝服务攻击 (DoS) 对存在该漏洞的系统的破坏效力。两者的主要区别在于 CVE-2018-5391 可通过 IP 连接加以利用。为涵盖这两个漏洞，我们更新了此公告。

说明

CVE-2018-5390（“SegmentSmack”）描述了一个内核级的网络漏洞，它可提高经由 TCP 连接的 DoS（拒绝服务）攻击对存在该漏洞的系统的破坏效力。

CVE-2018-5391（“FragmentSmack”）描述了一个内核级的网络漏洞，它可提高经由 IP 连接的 DoS（拒绝服务）攻击对存在该漏洞的系统的破坏效力。

对 Google Kubernetes Engine 的影响

截至 2018 年 8 月 11 日，所有 Kubernetes Engine 主节点都可以抵御对这两个漏洞的攻击。此外，所有配置为自动升级的 Kubernetes Engine 集群也可以抵御这类攻击。未配置为自动升级且最后一次手动升级是在 2018 年 8 月 11 日之前的 Kubernetes Engine 节点池会受到这两个漏洞的影响。

修补版本

鉴于此漏洞的严重级别，我们建议您在补丁程序可用时立即手动升级您的节点。

高

2018 年 5 月 30 日

说明严重程度备注

说明	严重程度	备注
最近在 Git 中发现了一个漏洞。如果允许无特权的用户创建使用 gitRepo 卷的 Pod，则可能会允许 Kubernetes 中的权限提升。此 CVE 标识为 CVE-2018-11235。我会受到影响吗？如果满足以下所有条件，则此漏洞会影响到您：不受信任的用户可以创建 Pod（或触发 Pod 的创建）。由不受信任的用户创建的 Pod 被限制访问主机根目录（例如，通过 PodSecurityPolicy）。由不受信任的用户创建的 Pod 被允许使用 gitRepo 卷类型。所有 Kubernetes Engine 节点都受此漏洞的影响。该怎么做？禁止使用 gitRepo 卷类型。如需通过 PodSecurityPolicy 禁止 gitRepo 卷，请从 PodSecurityPolicy 的 `volumes` 许可名单中删掉 `gitRepo`。通过从 initContainer 将 git 代码库克隆到 EmptyDir 卷中，可以实现等效的 gitRepo 卷行为： apiVersion: v1 kind: Pod metadata: name: git-repo-example spec: initContainers: # This container clones the desired git repo to the EmptyDir volume. - name: git-clone image: alpine/git # Any image with git will do args: - clone - --single-branch - -- - https://github.com/kubernetes/kubernetes # Your repo - /repo # Put it in the volume securityContext: runAsUser: 1 # Any non-root user will do. Match to the workload. allowPrivilegeEscalation: false readOnlyRootFilesystem: true volumeMounts: - name: git-repo mountPath: /repo containers: ... volumes: - name: git-repo emptyDir: {} 哪个补丁程序可解决这个漏洞？即将发布的 Kubernetes Engine 版本中将包含一个补丁程序。请稍后查看此处了解详情。	中	CVE-2018-11235

最近在 Git 中发现了一个漏洞。如果允许无特权的用户创建使用 gitRepo 卷的 Pod，则可能会允许 Kubernetes 中的权限提升。此 CVE 标识为 CVE-2018-11235。

我会受到影响吗？

如果满足以下所有条件，则此漏洞会影响到您：

不受信任的用户可以创建 Pod（或触发 Pod 的创建）。
由不受信任的用户创建的 Pod 被限制访问主机根目录（例如，通过 PodSecurityPolicy）。
由不受信任的用户创建的 Pod 被允许使用 gitRepo 卷类型。

所有 Kubernetes Engine 节点都受此漏洞的影响。

该怎么做？

禁止使用 gitRepo 卷类型。如需通过 PodSecurityPolicy 禁止 gitRepo 卷，请从 PodSecurityPolicy 的 volumes 许可名单中删掉 gitRepo。

通过从 initContainer 将 git 代码库克隆到 EmptyDir 卷中，可以实现等效的 gitRepo 卷行为：

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

哪个补丁程序可解决这个漏洞？

即将发布的 Kubernetes Engine 版本中将包含一个补丁程序。请稍后查看此处了解详情。

中

CVE-2018-11235

2018 年 5 月 21 日

说明	严重程度	备注
最近在 Linux 内核中发现了多个漏洞，这些漏洞可能会允许无特权的进程提升其权限或开展拒绝服务攻击（通过内核崩溃）。这些 CVE 标识为 CVE-2018-1000199、CVE-2018-8897 和 CVE-2018-1087。所有 Kubernetes Engine 节点都会受到这些漏洞的影响，我们建议您升级到最新的补丁程序版本，具体说明如下所述。该怎么做？若要升级，您必须先将主节点升级到最新版本。Kubernetes Engine 1.8.12-gke.1、Kubernetes Engine 1.9.7-gke.1 和 Kubernetes Engine 1.10.2-gke.1 中提供了相应补丁程序。这些版本包含 Container-Optimized OS 和 Ubuntu 映像的补丁程序。如果在此之前创建新集群，您必须指定修补后的版本，才能获得相应补丁程序。对于已启用节点自动升级且未进行手动升级的客户，其节点将会在未来几周内升级到修补后的版本。该补丁程序解决了哪些漏洞？该补丁程序缓解了以下漏洞： CVE-2018-1000199：此漏洞影响到 Linux 内核。它允许无特权的用户或进程引发系统内核崩溃，继而导致 DoS 攻击或权限提升。此漏洞被评为高危漏洞且 CVSS 的评分为 7.8。 CVE-2018-8897：此漏洞影响到 Linux 内核。它允许无特权的用户或进程引发系统内核崩溃，继而导致 DoS 攻击。此漏洞被评为中危漏洞且 CVSS 的评分为 6.5。 CVE-2018-1087：此漏洞影响到 Linux 内核的 KVM 管理程序。它允许无特权的进程引发客机内核崩溃或有可能获得特权。运行 Kubernetes Engine 的基础架构已修补此漏洞，因此 Kubernetes Engine 不会受到影响。此漏洞被评为高危漏洞且 CVSS 的评分为 8.0。	高	CVE-2018-1000199 CVE-2018-8897 CVE-2018-1087

说明

严重程度

备注

最近在 Linux 内核中发现了多个漏洞，这些漏洞可能会允许无特权的进程提升其权限或开展拒绝服务攻击（通过内核崩溃）。这些 CVE 标识为 CVE-2018-1000199、CVE-2018-8897 和 CVE-2018-1087。所有 Kubernetes Engine 节点都会受到这些漏洞的影响，我们建议您升级到最新的补丁程序版本，具体说明如下所述。

该怎么做？

若要升级，您必须先将主节点升级到最新版本。Kubernetes Engine 1.8.12-gke.1、Kubernetes Engine 1.9.7-gke.1 和 Kubernetes Engine 1.10.2-gke.1 中提供了相应补丁程序。这些版本包含 Container-Optimized OS 和 Ubuntu 映像的补丁程序。

如果在此之前创建新集群，您必须指定修补后的版本，才能获得相应补丁程序。对于已启用节点自动升级且未进行手动升级的客户，其节点将会在未来几周内升级到修补后的版本。

该补丁程序解决了哪些漏洞？

该补丁程序缓解了以下漏洞：

CVE-2018-1000199：此漏洞影响到 Linux 内核。它允许无特权的用户或进程引发系统内核崩溃，继而导致 DoS 攻击或权限提升。此漏洞被评为高危漏洞且 CVSS 的评分为 7.8。

CVE-2018-8897：此漏洞影响到 Linux 内核。它允许无特权的用户或进程引发系统内核崩溃，继而导致 DoS 攻击。此漏洞被评为中危漏洞且 CVSS 的评分为 6.5。

CVE-2018-1087：此漏洞影响到 Linux 内核的 KVM 管理程序。它允许无特权的进程引发客机内核崩溃或有可能获得特权。运行 Kubernetes Engine 的基础架构已修补此漏洞，因此 Kubernetes Engine 不会受到影响。此漏洞被评为高危漏洞且 CVSS 的评分为 8.0。

高

2018 年 3 月 12 日

说明	严重程度	备注
Kubernetes 项目最近披露了新的安全漏洞 CVE-2017-1002101 和 CVE-2017-1002102，这些漏洞允许容器访问该容器之外的文件。所有 Kubernetes Engine 节点都会受到这些漏洞的影响，我们建议您尽快升级到最新的补丁程序版本，具体说明如下所述。该怎么做？鉴于这些漏洞的严重级别，无论您是否启用了节点自动升级，我们都建议您在补丁程序可用时立即手动升级您的节点。该补丁程序将于 3 月 16 日之前提供给所有客户，但根据您的集群所在的区域，您也可能会更早获得该补丁程序，具体请参照发布计划。若要升级，您必须先将主节点升级到最新版本。Kubernetes 1.9.4-gke.1、Kubernetes 1.8.9-gke.1 和 Kubernetes 1.7.14-gke.1 中提供了相应补丁程序。默认情况下，新集群将在 3 月 30 日使用修补后的版本；如果在此之前创建新集群，则必须指定修补后的版本，才能获得相应补丁程序。对于已启用节点自动升级且不进行手动升级的客户，其节点将会在 4 月 23 日之前升级到修补后的版本。不过，鉴于此漏洞的性质，我们建议您在补丁程序可用时立即手动升级您的节点。该补丁程序解决了哪些漏洞？该补丁程序缓解了以下两个漏洞：漏洞 CVE-2017-1002101 允许使用子路径卷装载功能的容器访问卷外部的文件。这意味着，如果您使用 PodSecurityPolicy 来阻止容器访问主机路径卷，则可更新或创建 Pod 的攻击者将能够使用任何其他卷类型来装载任何主机路径。漏洞 CVE-2017-1002102 允许使用某些卷类型（包括 Secret 卷、ConfigMap 卷、映射卷或 Downward API 卷）的容器删除该卷外部的文件。这意味着，如果使用其中一种卷类型的容器遭到破解，或者您允许不受信任的用户创建 Pod，则攻击者可以使用该容器删除主机上的任意文件。如需详细了解此修复程序，请参阅 Kubernetes 博文。	高	CVE-2017-1002101 CVE-2017-1002102

说明

严重程度

备注

Kubernetes 项目最近披露了新的安全漏洞 CVE-2017-1002101 和 CVE-2017-1002102，这些漏洞允许容器访问该容器之外的文件。所有 Kubernetes Engine 节点都会受到这些漏洞的影响，我们建议您尽快升级到最新的补丁程序版本，具体说明如下所述。

该怎么做？

鉴于这些漏洞的严重级别，无论您是否启用了节点自动升级，我们都建议您在补丁程序可用时立即手动升级您的节点。该补丁程序将于 3 月 16 日之前提供给所有客户，但根据您的集群所在的区域，您也可能会更早获得该补丁程序，具体请参照发布计划。

若要升级，您必须先将主节点升级到最新版本。Kubernetes 1.9.4-gke.1、Kubernetes 1.8.9-gke.1 和 Kubernetes 1.7.14-gke.1 中提供了相应补丁程序。默认情况下，新集群将在 3 月 30 日使用修补后的版本；如果在此之前创建新集群，则必须指定修补后的版本，才能获得相应补丁程序。

对于已启用节点自动升级且不进行手动升级的客户，其节点将会在 4 月 23 日之前升级到修补后的版本。不过，鉴于此漏洞的性质，我们建议您在补丁程序可用时立即手动升级您的节点。

该补丁程序解决了哪些漏洞？

该补丁程序缓解了以下两个漏洞：

漏洞 CVE-2017-1002101 允许使用子路径卷装载功能的容器访问卷外部的文件。这意味着，如果您使用 PodSecurityPolicy 来阻止容器访问主机路径卷，则可更新或创建 Pod 的攻击者将能够使用任何其他卷类型来装载任何主机路径。

漏洞 CVE-2017-1002102 允许使用某些卷类型（包括 Secret 卷、ConfigMap 卷、映射卷或 Downward API 卷）的容器删除该卷外部的文件。这意味着，如果使用其中一种卷类型的容器遭到破解，或者您允许不受信任的用户创建 Pod，则攻击者可以使用该容器删除主机上的任意文件。

如需详细了解此修复程序，请参阅 Kubernetes 博文。

高

Google Distributed Cloud 安全公告

2019 年 10 月 16 日

说明	严重程度	备注
近期在 Kubernetes 中发现了一个漏洞（如 CVE-2019-11253 中所述），该漏洞导致任何有权发出 POST 请求的用户都可以对 Kubernetes API 服务器执行远程拒绝服务攻击。Kubernetes 产品安全委员会 (PSC) 已经发布了有关此漏洞的更多信息，详见此处。您可以通过限制哪些客户端能够经由网络访问您的 Kubernetes API 服务器来缓解此漏洞。该怎么做？我们建议您在包含修复方案的补丁程序版本发布后，尽快将集群升级到相应补丁程序版本。下面列出了将包含此修复的补丁程序版本： GKE Enterprise 1.1.1，运行 Kubernetes 1.13.7-gke.30 版该补丁程序解决了什么漏洞？该补丁程序缓解了以下漏洞：CVE-2019-11253。	高	CVE-2019-11253

说明

严重程度

备注

近期在 Kubernetes 中发现了一个漏洞（如 CVE-2019-11253 中所述），该漏洞导致任何有权发出 POST 请求的用户都可以对 Kubernetes API 服务器执行远程拒绝服务攻击。Kubernetes 产品安全委员会 (PSC) 已经发布了有关此漏洞的更多信息，详见此处。

您可以通过限制哪些客户端能够经由网络访问您的 Kubernetes API 服务器来缓解此漏洞。

该怎么做？

我们建议您在包含修复方案的补丁程序版本发布后，尽快将集群升级到相应补丁程序版本。

下面列出了将包含此修复的补丁程序版本：

GKE Enterprise 1.1.1，运行 Kubernetes 1.13.7-gke.30 版

该补丁程序解决了什么漏洞？

该补丁程序缓解了以下漏洞：CVE-2019-11253。

高

CVE-2019-11253

2019 年 8 月 23 日

说明严重程度备注

说明	严重程度	备注
我们最近发现并缓解了一个漏洞，在该漏洞中，用于保护监控端点的 RBAC 代理未正确授权用户。因此，内部集群网络中未授权用户可以访问某些组件的指标。以下组件受到了影响： `etcd` `etcd-events` `kube-apiserver` `kube-controller-manager` `kube-scheduler` `node-exporter` `kube-state-metrics` `prometheus` `alertmanager` 该怎么做？我们建议您尽快将集群升级到 1.0.2-gke.3 版，其中包含此漏洞的补丁程序。	中	Google Distributed Cloud 版本

我们最近发现并缓解了一个漏洞，在该漏洞中，用于保护监控端点的 RBAC 代理未正确授权用户。因此，内部集群网络中未授权用户可以访问某些组件的指标。以下组件受到了影响：

etcd
etcd-events
kube-apiserver
kube-controller-manager
kube-scheduler
node-exporter
kube-state-metrics
prometheus
alertmanager

该怎么做？

我们建议您尽快将集群升级到 1.0.2-gke.3 版，其中包含此漏洞的补丁程序。

中

Google Distributed Cloud 版本

2019 年 8 月 22 日

说明	严重程度	备注
Kubernetes 最近发现了一个漏洞 (CVE-2019-11247)，该漏洞允许集群级的自定义资源实例像存在于所有命名空间内的有命名空间对象一样得到处理。这意味着仅有命名空间级 RBAC 权限的用户和服务账号可以与集群级自定义资源交互。利用此漏洞要求攻击者具有访问任意命名空间内资源的权限。该怎么做？我们建议您尽快将集群升级到 1.0.2-gke.3 版，其中包含此漏洞的补丁程序。该补丁程序解决了什么漏洞？该补丁程序缓解了以下漏洞：CVE-2019-11247。	中	CVE-2019-11247

说明

严重程度

备注

该怎么做？

我们建议您尽快将集群升级到 1.0.2-gke.3 版，其中包含此漏洞的补丁程序。

该补丁程序解决了什么漏洞？

该补丁程序缓解了以下漏洞：CVE-2019-11247。

中

CVE-2019-11247