安全公告

本页介绍以下产品的所有安全公告:

  • Google Kubernetes Engine (GKE)
  • Anthos clusters on VMware (GKE on-prem)
  • Anthos clusters on AWS (GKE on AWS)
  • Anthos clusters on Bare Metal

漏洞通常有一段时间的保密期,以便给受影响的各方留出时间来解决这些问题。在这种情况下,产品的版本说明会在保密期结束前使用“安全更新”来泛指这些漏洞。保密期结束后,我们会更新版本说明,以阐明补丁程序所解决的漏洞。

如需详细了解 Google 如何管理 GKE 和 Anthos 的安全漏洞和补丁程序,请参阅安全修补

使用此 XML Feed 可订阅此页面的安全公告。 订阅

GCP-2021-024

发布日期:2021-10-21
参考编号CVE-2021-25742

GKE

说明 严重程度

在 Kubernetes ingress-nginx 控制器中发现了安全问题 (CVE-2021-25742)。ingress-nginx 自定义代码段允许检索所有命名空间中的 ingress-nginx 服务帐号令牌和 Secret。

该怎么做?

此安全问题不会影响 GKE 集群基础架构或任何 Anthos 环境集群基础架构。如果您在工作负载部署中使用 ingress-nginx,则应注意此安全问题。如需了解详情,请参阅 ingress-nginx 问题 7837

Anthos clusters on

说明 严重程度

在 Kubernetes ingress-nginx 控制器中发现了安全问题 (CVE-2021-25742)。ingress-nginx 自定义代码段允许检索所有命名空间中的 ingress-nginx 服务帐号令牌和 Secret。

该怎么做?

此安全问题不会影响 GKE 集群基础架构或任何 Anthos 环境集群基础架构。如果您在工作负载部署中使用 ingress-nginx,则应注意此安全问题。如需了解详情,请参阅 ingress-nginx 问题 7837

Anthos clusters on

说明 严重程度

在 Kubernetes ingress-nginx 控制器中发现了安全问题 (CVE-2021-25742)。ingress-nginx 自定义代码段允许检索所有命名空间中的 ingress-nginx 服务帐号令牌和 Secret。

该怎么做?

此安全问题不会影响 GKE 集群基础架构或任何 Anthos 环境集群基础架构。如果您在工作负载部署中使用 ingress-nginx,则应注意此安全问题。如需了解详情,请参阅 ingress-nginx 问题 7837

Anthos clusters on

说明 严重程度

在 Kubernetes ingress-nginx 控制器中发现了安全问题 (CVE-2021-25742)。ingress-nginx 自定义代码段允许检索所有命名空间中的 ingress-nginx 服务帐号令牌和 Secret。

该怎么做?

此安全问题不会影响 GKE 集群基础架构或任何 Anthos 环境集群基础架构。如果您在工作负载部署中使用 ingress-nginx,则应注意此安全问题。如需了解详情,请参阅 ingress-nginx 问题 7837

GCP-2021-019

发布时间:2021 年 9 月 29 日

GKE

说明 严重程度

存在一个已知问题,即使用 v1beta1 API 更新 BackendConfig 资源会从其 Service 中移除活跃的 Google Cloud Armor 安全政策。

我会受到影响吗?

如果您已使用 v1beta1 API 更新了 BackendConfig,则您的 Google Cloud Armor 安全政策可能已被移除。要确定是否发生了这种情况,请运行以下命令


kubectl get backendconfigs -A -o json | \
jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
  • 如果响应返回输出,则您的集群会受到问题的影响。此命令的输出会返回受此问题影响的 BackendConfig 资源 (<namespace>/<name>) 列表。
  • 如果输出为空,则说明由于该问题的出现,BackendConfig 尚未使用 v1beta1 API 进行更新。BackendConfig 的任何未来更新都应仅使用 v1

此问题会影响以下 GKE 版本:

  • 1.18.19-gke.1400 至 1.18.20-gke.5100(不含边界值)
  • 1.19.10-gke.700 至 1.19.14-gke.300(不含边界值)
  • 1.20.6-gke.700 至 1.20.9-gke.900(不含边界值)
  • 1.21 至 1.21.1-gke.2700(不含边界值)

如果您未通过 BackendConfig 在 Ingress 资源上配置 Google Cloud Armor,则此问题不会影响您的集群。

该怎么做?

将 GKE 控制平面升级到以下更新后的版本之一,该版本可以修补此问题并允许安全使用 v1beta1 BackendConfig 资源:

  • 1.21.1-gke.2700 及更高版本
  • 1.20.9-gke.900 及更高版本
  • 1.19.14-gke.300 及更高版本
  • 1.18.20-gke.5100 及更高版本

此问题也可以通过避免部署 v1beta1 BackendConfig 资源来防止。如果您通过 BackendConfig 在 Ingress 资源上配置 Google Cloud Armor,并且发现受到上述步骤影响了您,请通过将含有 cloud.google.com/v1 API 版本的更新推送到当前 BackendConfig 资源来重新启用 Google Cloud Armor。

为防止此问题,请仅使用 v1 BackendConfig API 更新 BackendConfig

由于 v1 BackendConfig 支持与 v1beta1 相同的所有字段,并且不会发生重大更改,因此可以透明地更新 API 字段。为此,将任何活动 BackendConfig 清单的 apiVersion 字段替换cloud.google.com/v1 而不是使用 cloud.google.com/v1beta1

以下示例清单描述了使用 v1 API 的 BackendConfig 资源:


apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backend-config
spec:
  securityPolicy:
    name: "ca-how-to-security-policy"

如果您有定期更新 BackendConfig 资源的 CI/CD 系统或工具,请确保您在这些系统中使用 cloud.google.com/v1 API 组

GCP-2021-022

发布日期:2021-09-23

Anthos clusters on

说明 严重程度

在 Anthos clusters on VMware 版本 1.8 和 1.8.1 的 Anthos Identity Service (AIS) LDAP 模块中发现了一个漏洞,在该漏洞中,用于生成密钥的种子密钥是可预测的。利用此漏洞,经过身份验证的用户可以无限期地添加任意声明和提升权限。

技术详情

最近给 AIS 代码添加了内容,以使用 golang 的 math/rand 模块创建对称密钥,但此类模块不适用于安全敏感代码。该模块的使用方式会生成可预测的密钥。在身份验证期间,系统会生成安全令牌服务 (STS) 密钥,该密钥随后使用易于派生的对称密钥进行加密。

该怎么做?

此漏洞仅影响在 Anthos clusters on VMware 1.8 和 1.8.1 版中使用 AIS 的客户。对于 Anthos clusters on VMware 1.8 的用户,请将集群升级到以下版本:

  • 1.8.2

GCP-2021-021

发布日期:2021-09-22
参考编号CVE-2020-8561

GKE

说明 严重程度

在 Kubernetes 中发现了一个安全漏洞 CVE-2020-8561,某些网络钩子可以将 kube-apiserver 请求重定向到该 API 服务器的专用网络。

技术详情

利用此漏洞,控制 MutatingWebhookConfigurationValidatingWebhookConfiguration 请求响应的操作者能够将 kube-apiserver 请求重定向到 API 服务器的专用网络。如果该用户在日志级别设置为 10 时可以查看 kube-apiserver 日志,则可以查看日志中的重定向响应和标头。

您可以通过更改 API 服务器的特定参数来缓解此问题。

该怎么做?

目前不需要采取任何措施。

目前可用的 GKE 和 Anthos 版本已实施以下缓解措施来抵御此类攻击:

  • kube-apiserver--profiling 标志设置为 false
  • kube-apiserver 日志级别设置为低于 10

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

CVE-2020-8561

Anthos clusters on

说明 严重程度

在 Kubernetes 中发现了一个安全漏洞 CVE-2020-8561,某些网络钩子可以将 kube-apiserver 请求重定向到该 API 服务器的专用网络。

技术详情

利用此漏洞,控制 MutatingWebhookConfigurationValidatingWebhookConfiguration 请求响应的操作者能够将 kube-apiserver 请求重定向到 API 服务器的专用网络。如果该用户在日志级别设置为 10 时可以查看 kube-apiserver 日志,则可以查看日志中的重定向响应和标头。

您可以通过更改 API 服务器的特定参数来缓解此问题。

该怎么做?

目前不需要采取任何措施。

目前可用的 GKE 和 Anthos 版本已实施以下缓解措施来抵御此类攻击:

  • kube-apiserver--profiling 标志设置为 false
  • kube-apiserver 日志级别设置为低于 10

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

CVE-2020-8561

Anthos clusters on

说明 严重程度

在 Kubernetes 中发现了一个安全漏洞 CVE-2020-8561,某些网络钩子可以将 kube-apiserver 请求重定向到该 API 服务器的专用网络。

技术详情

利用此漏洞,控制 MutatingWebhookConfigurationValidatingWebhookConfiguration 请求响应的操作者能够将 kube-apiserver 请求重定向到 API 服务器的专用网络。如果该用户在日志级别设置为 10 时可以查看 kube-apiserver 日志,则可以查看日志中的重定向响应和标头。

您可以通过更改 API 服务器的特定参数来缓解此问题。

该怎么做?

目前不需要采取任何措施。

目前可用的 GKE 和 Anthos 版本已实施以下缓解措施来抵御此类攻击:

  • kube-apiserver--profiling 标志设置为 false
  • kube-apiserver 日志级别设置为低于 10

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

CVE-2020-8561

Anthos clusters on

说明 严重程度

在 Kubernetes 中发现了一个安全漏洞 CVE-2020-8561,某些网络钩子可以将 kube-apiserver 请求重定向到该 API 服务器的专用网络。

技术详情

利用此漏洞,控制 MutatingWebhookConfigurationValidatingWebhookConfiguration 请求响应的操作者能够将 kube-apiserver 请求重定向到 API 服务器的专用网络。如果该用户在日志级别设置为 10 时可以查看 kube-apiserver 日志,则可以查看日志中的重定向响应和标头。

您可以通过更改 API 服务器的特定参数来缓解此问题。

该怎么做?

目前不需要采取任何措施。

目前可用的 GKE 和 Anthos 版本已实施以下缓解措施来抵御此类攻击:

  • kube-apiserver--profiling 标志设置为 false
  • kube-apiserver 日志级别设置为低于 10

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

CVE-2020-8561

GCP-2021-018

发布日期:2021-09-15
更新日期:2021-09-24
参考编号CVE-2021-25741

2021-09-24 更新:Anthos clusters on Bare Metal 公告已更新,新增了一些修补版本。

2021-09-20 更新:添加了针对 Anthos clusters on Bare Metal 的公告

2021-09-16 更新:添加了针对 Anthos clusters on VMware 的公告


GKE

说明 严重程度

您好!在 Kubernetes 中发现了一个安全问题(如 CVE-2021-25741 中所述),导致用户可以创建具有子路径卷挂载的容器来访问卷外部的文件和目录,包括主机文件系统。

技术详情:

在 CVE-2021-25741 中,攻击者可以创建从装载的 emptyDir 到节点根文件系统 ( / ) 的符号链接,而 kubelet 将遵循符号链接,并将主机根目录装载到容器中。

该怎么做?

我们建议您将节点池升级到以下版本之一或更高版本,以利用最新补丁程序:

  • 1.21.4-gke.301
  • 1.20.10-gke.301
  • 1.19.14-gke.301
  • 1.18.20-gke.4501

以下版本还包含修复:

  • 1.21.3-gke.2001
  • 1.20.8-gke.2101
  • 1.20.9-gke.701
  • 1.20.9-gke.1001
  • 1.19.12-gke.2101
  • 1.19.13-gke.701
  • 1.18.20-gke.3001

Anthos clusters on

说明 严重程度

您好!在 Kubernetes 中发现了一个安全问题(如 CVE-2021-25741 中所述),导致用户可以创建具有子路径卷挂载的容器来访问卷外部的文件和目录,包括主机文件系统。

技术详情:

在 CVE-2021-25741 中,攻击者可以创建从装载的 emptyDir 到节点根文件系统 ( / ) 的符号链接,而 kubelet 将遵循符号链接,并将主机根目录装载到容器中。

该怎么做?

2021-09-24 更新:修补版本 1.8.3 和 1.7.4 现已发布。

2021-09-17 更新:更正了包含补丁程序的可用版本列表。


以下版本的 Anthos clusters on VMware 已进行了代码更新,以修复此漏洞。将管理员集群和用户集群升级到以下版本之一:

  • 1.8.3
  • 1.8.2
  • 1.7.4
  • 1.6.5

Anthos clusters on

说明 严重程度

您好!在 Kubernetes 中发现了一个安全问题(如 CVE-2021-25741 中所述),导致用户可以创建具有子路径卷挂载的容器来访问卷外部的文件和目录,包括主机文件系统。

技术详情:

在 CVE-2021-25741 中,攻击者可以创建从装载的 emptyDir 到节点根文件系统 ( / ) 的符号链接,而 kubelet 将遵循符号链接,并将主机根目录装载到容器中。

该怎么做?

2021-9-16 更新:添加了 AWSClusterAWSNodePool 对象支持的 gke 版本的列表。


以下版本的 Anthos clusters on AWS 已进行了代码更新,以修复此漏洞。建议您执行以下操作:

  • AWSManagementServiceAWSClusterAWSNodePool 对象升级到以下版本:
    • 1.8.2
  • AWSClusterAWSNodePool 对象的 gke 版本更新为以下某个受支持的 Kubernetes 版本
    • 1.17.17-gke.15800
    • 1.18.20-gke.4800
    • 1.19.14-gke.600
    • 1.20.10-gke.600

Anthos clusters on

说明 严重程度

您好!在 Kubernetes 中发现了一个安全问题(如 CVE-2021-25741 中所述),导致用户可以创建具有子路径卷挂载的容器来访问卷外部的文件和目录,包括主机文件系统。

技术详情:

在 CVE-2021-25741 中,攻击者可以创建从装载的 emptyDir 到节点根文件系统 ( / ) 的符号链接,而 kubelet 将遵循符号链接,并将主机根目录装载到容器中。

该怎么做?

为了修复此漏洞,我们已对以下版本的 Anthos on Bare Metal 进行了代码更新。将管理员集群和用户集群升级到以下版本之一:

  • 1.8.3
  • 1.7.4

GCP-2021-017

发布日期:2021-09-01
更新日期:2021-09-23
参考编号CVE-2021-33909
CVE-2021-33910

GKE

说明 严重程度
2021-09-23 更新:

对于源自 GKE Sandbox 中运行的容器的攻击,这些容器不受此漏洞影响。


2021-09-15 更新:

以下 GKE 版本解决了这些漏洞:

  • 1.18.20-gke.4100
  • 1.19.13-gke.1900
  • 1.20.9-gke.1500
  • 1.21.3-gke.1400

在 Linux 内核中发现了两个安全漏洞 CVE-2021-33909CVE-2021-33910,可能会导致操作系统崩溃或由无特权用户升级为 root 用户。此漏洞会影响所有 GKE 节点操作系统(COS 和 Ubuntu)。

技术详情:

CVE-2021-33909 中,Linux 内核的文件系统层未正确限制 seq 缓冲区分配,从而导致整数溢出、超出范围写入以及提升至 root。
CVE-2021-33910 中,systemd 分配的内存大小值过大(涉及针对本地攻击者控制的路径名的 strdupaalloca),导致操作系统崩溃。

该怎么做?

以下版本的 GKE 的 Linux 节点映像版本已更新,内含修复此漏洞的代码。将集群升级到以下版本之一:

  • 1.18.20-gke.4100
  • 1.19.13-gke.1900
  • 1.20.9-gke.1500
  • 1.21.3-gke.1400

Anthos clusters on

说明 严重程度

在 Linux 内核中发现了两个安全漏洞 CVE-2021-33909CVE-2021-33910,可能会导致操作系统崩溃或由无特权用户升级为 root 用户。此漏洞会影响所有 GKE 节点操作系统(COS 和 Ubuntu)。

技术详情:

CVE-2021-33909 中,Linux 内核的文件系统层未正确限制 seq 缓冲区分配,从而导致整数溢出、超出范围写入以及提升至 root。
CVE-2021-33910 中,systemd 分配的内存大小值过大(涉及针对本地攻击者控制的路径名的 strdupaalloca),导致操作系统崩溃。

该怎么做?

Anthos clusters on AWS 的 Linux 节点映像版本已更新,内含修复此漏洞的代码。将集群升级到以下版本之一:

  • 1.20.10-gke.600
  • 1.19.14-gke.600
  • 1.18.20-gke.4800
  • 1.17.17-gke.15800

Anthos clusters on

说明 严重程度

在 Linux 内核中发现了两个安全漏洞 CVE-2021-33909CVE-2021-33910,可能会导致操作系统崩溃或由无特权用户升级为 root 用户。此漏洞会影响所有 GKE 节点操作系统(COS 和 Ubuntu)。

技术详情:

CVE-2021-33909 中,Linux 内核的文件系统层未正确限制 seq 缓冲区分配,从而导致整数溢出、超出范围写入以及提升至 root。
CVE-2021-33910 中,systemd 分配的内存大小值过大(涉及针对本地攻击者控制的路径名的 strdupaalloca),导致操作系统崩溃。

该怎么做?

Anthos clusters on VMware 的 Linux 和 COS 节点映像版本已更新代码以修复此漏洞。将集群升级到以下版本之一:

  • 1.9
  • 1.8.2
  • 1.7.3
  • 1.6.4(仅限 Linux)

请参阅版本历史记录 - Kubernetes 和节点内核版本

GCP-2021-015

发布日期:2021-07-13
更新日期:2021-07-15
参考编号CVE-2021-22555

GKE

说明 严重程度

发现了新的安全漏洞 CVE-2021-22555,即具有 CAP_NET_ADMIN 特权的恶意操作者有可能会在宿主机上引发容器入侵。此漏洞会影响运行 Linux 2.6.19 或更高版本的所有 GKE 集群和 Anthos clusters on VMware。

技术详情

在这种攻击中,Linux 的 netfilter 子系统中的 setsockopt 越界写入可能会导致堆损坏(进而导致拒绝服务攻击)和特权提升。

该怎么做?

以下版本的 Linux on GKE 已更新,内含修复此漏洞的代码。将集群升级到以下版本之一:

  • 1.21.1-gke.2200
  • 1.20.7-gke.2200
  • 1.19.11-gke.2100
  • 1.18.20-gke.501

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

CVE-2021-22555

Anthos clusters on

说明 严重程度

发现了新的安全漏洞 CVE-2021-22555,即具有 CAP_NET_ADMIN 特权的恶意操作者有可能会在宿主机上引发容器入侵。此漏洞会影响运行 Linux 2.6.19 或更高版本的所有 GKE 集群和 Anthos clusters on VMware。

技术详情

在这种攻击中,Linux 的 netfilter 子系统中的 setsockopt 越界写入可能会导致堆损坏(进而导致拒绝服务攻击)和特权提升。

该怎么做?

Anthos clusters on VMware 上的以下 Linux 版本已更新,内含修复此漏洞的代码。将集群升级到以下版本之一:

  • 1.8
  • 1.7.3
  • 1.6.4

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

CVE-2021-22555

GCP-2021-014

发布日期:2021-07-05
参考编号CVE-2021-34527

GKE

说明 严重程度

Microsoft 发布了有关远程代码执行 (RCE) 漏洞的安全公告 CVE-2021-34527,该漏洞会影响 Windows 服务器的打印假脱机程序。CERT 协调中心 (CERT/CC) 发布了一个相关漏洞的更新说明,该补丁程序名为“PrintNightmare”,也影响 Windows 打印后台处理程序 - PrintNightmare, Critical Windows Print Spooler Vulnerability

该怎么做?

您无需采取任何操作。GKE Windows 节点不包含受影响的 Spooler 服务作为基础映像的一部分,因此 GKE Windows 部署不容易受到此攻击。

该公告解决了哪些漏洞?

GCP-2021-012

发布日期:2021-07-01
更新日期:2021-07-09
参考编号CVE-2021-34824

GKE

说明 严重程度

该怎么做?

Istio 项目最近披露了影响 Istio 的新的安全漏洞 (CVE-2021-34824)。Istio 包含一个远程可利用的漏洞,攻击者可以利用该漏洞通过不同的命名空间访问网关和 DestinationRule credentialName 字段中指定的凭据。

技术详情:

Istio 安全网关使用 DestinationRule 的工作负载可以通过 credentialName 配置从 Kubernetes Secret 加载 TLS 私钥和证书。从 Istio 1.8 及更高版本开始,Secret 从 istiod 读取并通过 XDS 传送到网关和工作负载。

通常,网关或工作负载部署只能访问存储在其命名空间内 Secret 中的 TLS 证书和私钥。但是,istiod 中的错误允许有权访问 Istio XDS API 的客户端检索 istiod 中缓存的所有 TLS 证书和私钥。

该怎么做?

GKE 集群默认不会运行 Istio,不受此漏洞影响;如果已启用此功能,使用 Istio 1.6 版也不受此漏洞影响。如果您已在集群上安装或将其升级到 Istio 1.8 或更高版本,请将 Istio 升级到受支持的最新版本。

Anthos clusters on

说明 严重程度

该怎么做?

Istio 项目最近披露了影响 Istio 的新的安全漏洞 (CVE-2021-34824)。Istio 包含一个远程可利用的漏洞,攻击者可以利用该漏洞通过不同的命名空间访问网关和 DestinationRule credentialName 字段中指定的凭据。

技术详情:

Istio 安全网关使用 DestinationRule 的工作负载可以通过 credentialName 配置从 Kubernetes Secret 加载 TLS 私钥和证书。从 Istio 1.8 及更高版本开始,Secret 从 istiod 读取并通过 XDS 传送到网关和工作负载。

通常,网关或工作负载部署只能访问存储在其命名空间内 Secret 中的 TLS 证书和私钥。但是,istiod 中的错误允许有权访问 Istio XDS API 的客户端检索 istiod 中缓存的所有 TLS 证书和私钥。

该怎么做?

Anthos clusters on VMware v1.6 和 v1.7 均不受此漏洞影响。Anthos clusters on VMware v1.8 受此漏洞影响。

如果您使用的是 Anthos clusters on VMware v1.8,请升级到以下经过修补的版本或更高版本:

  • 1.8.0-gke.25

Anthos clusters on

说明 严重程度

该怎么做?

Istio 项目最近披露了影响 Istio 的新的安全漏洞 (CVE-2021-34824)。Istio 包含一个远程可利用的漏洞,攻击者可以利用该漏洞通过不同的命名空间访问网关和 DestinationRule credentialName 字段中指定的凭据。

技术详情:

Istio 安全网关使用 DestinationRule 的工作负载可以通过 credentialName 配置从 Kubernetes Secret 加载 TLS 私钥和证书。从 Istio 1.8 及更高版本开始,Secret 从 istiod 读取并通过 XDS 传送到网关和工作负载。

通常,网关或工作负载部署只能访问存储在其命名空间内 Secret 中的 TLS 证书和私钥。但是,istiod 中的错误允许有权访问 Istio XDS API 的客户端检索 istiod 中缓存的所有 TLS 证书和私钥。使用 Anthos clusters on Bare Metal v1.8.0 创建或升级的集群会受到此 CVE 的影响。

该怎么做?

Anthos v1.6 和 1.7 均不受此漏洞影响。如果您使用的是 v1.8.0 集群,请下载并安装 1.8.1 版本的 bmctl,并将您的集群升级到以下修补后的版本:

  • 1.8.1

GCP-2021-011

发布日期:2021-06-04
更新日期:2021-10-19
参考编号:CVE-2021-30465

2021 年 10 月 19 日更新:添加了 Anthos clusters on VMware、Anthos clusters on AWS 和 Anthos clusters on Bare Metal 的公告。

GKE

说明 严重程度

安全社区近期披露了在 runc 中发现的可能允许对节点文件系统进行完全访问的新安全漏洞 (CVE-2021-30465)。

对于 GKE,由于利用此漏洞需要具备创建 Pod 的能力,因此我们将此漏洞的严重性评级为中等。

技术详情

runc 软件包在装载卷时容易受到符号链接攻击。

对于此特定攻击,用户可能通过在同一节点上启动多个 pod(所有节点都通过符号链接共享同一个卷装载)来利用竞态条件。

如果攻击成功,其中一个 pod 将使用 root 权限装载节点的文件系统。

该怎么做?

runc 有新发布的补丁程序 (1.0.0-rc95),可修复此漏洞。

将 GKE 集群升级到以下更新版本之一:

  • 1.18.19-gke.2100
  • 1.19.9-gke.1400
  • 1.20.6-gke.1400
  • 1.21.2-gke.600

Anthos clusters on

说明 严重程度

安全社区近期披露了在 runc 中发现的可能允许对节点文件系统进行完全访问的新安全漏洞 (CVE-2021-30465)。

对于 Anthos Clusters on VMware,由于利用此漏洞需要创建 Pod 的权限,因此我们将此漏洞的严重级别评为中等。

技术详情

runc 软件包在装载卷时容易受到符号链接攻击。

对于此特定攻击,用户可能通过在同一节点上启动多个 pod(所有节点都通过符号链接共享同一个卷装载)来利用竞态条件。

如果攻击成功,其中一个 pod 将使用 root 权限装载节点的文件系统。

该怎么做?

runc 有新发布的补丁程序,可修复此漏洞。将 Anthos clusters on VMware 升级到以下版本之一:

  • 1.7.3-gke-2
  • 1.8.1-gke.7
  • 1.9.0-gke.8

Anthos clusters on

说明 严重程度

安全社区近期披露了在 runc 中发现的可能允许对节点文件系统进行完全访问的新安全漏洞 (CVE-2021-30465)。

由于 Anthos 是操作系统级别的漏洞,因此 Anthos clusters on AWS 不易受攻击。

技术详情

runc 软件包在装载卷时容易受到符号链接攻击。

对于此特定攻击,用户可能通过在同一节点上启动多个 pod(所有节点都通过符号链接共享同一个卷装载)来利用竞态条件。

如果攻击成功,其中一个 pod 将使用 root 权限装载节点的文件系统。

该怎么做?

确保将运行 Anthos clusters on AWS 的操作系统版本升级到具有更新后的 runc 软件包的最新操作系统版本。

Anthos clusters on

说明 严重程度

安全社区近期披露了在 runc 中发现的可能允许对节点文件系统进行完全访问的新安全漏洞 (CVE-2021-30465)。

由于 Anthos 是操作系统级别的漏洞,因此 Anthos clusters on Bare Metal 不易受攻击。

技术详情

runc 软件包在装载卷时容易受到符号链接攻击。

对于此特定攻击,用户可能通过在同一节点上启动多个 pod(所有节点都通过符号链接共享同一个卷装载)来利用竞态条件。

如果攻击成功,其中一个 pod 将使用 root 权限装载节点的文件系统。

该怎么做?

确保将运行 Anthos on Bare Metal 的操作系统版本升级到包含更新后的 runc 软件包的最新操作系统版本。

GCP-2021-006

发布日期:2021-05-11
参考编号CVE-2021-31920

GKE

说明 严重程度

Istio 项目最近披露了影响 Istio 的新的安全漏洞 (CVE-2021-31920)。

Istio 包含一个可远程利用的漏洞,在使用基于路径的授权规则时,如果 HTTP 请求包含多个斜杠或转义的斜杠字符,该请求可以绕过 Istio 授权政策。

该怎么做?

我们强烈建议您更新并重新配置 GKE 集群。请注意,您必须完成以下两个步骤,才能成功解决该漏洞:

  1. 更新集群:请按照以下说明尽快将集群升级到最新的补丁程序版本:
    • 如果您使用的是 Istio on GKE 1.6

      最新的补丁程序版本为 1.6.14-gke.3。请按照升级说明将集群升级到最新版本。

    • 如果您使用的是 Istio on GKE 1.4
    • Istio 不再支持 Istio on GKE 1.4 版本,并且我们会将 CVE 修复程序向后移植到这些版本。请按照 Istio 升级说明将集群升级到 1.6 版,然后按上述说明获取最新版本的 Istio on GKE 1.6。

  2. 配置 Istio

    修补集群后,您必须重新配置 Istio on GKE。请参阅安全最佳做法指南,正确配置您的系统。

GCP-2021-004

发布日期:2021-05-06
参考编号CVE-2021-28683CVE-2021-28682CVE-2021-29258

GKE

说明 严重程度

Envoy 和 Istio 项目最近公布了几个新的安全漏洞(CVE-2021-28683CVE-2021-28682CVE-2021-29258),攻击者可能会利用这些漏洞使 Envoy 崩溃。

GKE 集群默认不会运行 Istio,不受此漏洞影响。如果 Istio 已安装在集群中并配置为在互联网上公开服务,这些服务可能容易受到拒绝服务攻击。

该怎么做?

要修复这些漏洞,请将 GKE 控制层面升级到以下某个修补后的版本:

  • 1.16.15-gke.16200
  • 1.17.17-gke.6100
  • 1.18.17-gke.1300
  • 1.19.9-gke.1300
  • 1.20.5-gke.1400

Anthos clusters on

说明 严重程度

Envoy 和 Istio 项目最近公布了几个新的安全漏洞(CVE-2021-28683CVE-2021-28682CVE-2021-29258),攻击者可能会利用这些漏洞使 Envoy 崩溃。

Anthos clusters on VMware 默认将 Envoy 用于 Ingress,因此 Ingress 服务可能容易遭到拒绝服务攻击。

该怎么做?

要修复这些漏洞,请将 Anthos clusters on VMware 升级到以下某个修补后的版本:

  • 1.5.4
  • 1.6.3
  • 1.7.1

Anthos clusters on

更新日期:2021-05-06

说明 严重程度

Envoy 和 Istio 项目最近公布了几个新的安全漏洞(CVE-2021-28683CVE-2021-28682CVE-2021-29258),攻击者可能会利用这些漏洞使 Envoy 崩溃。

Anthos on Bare Metal 默认将 Envoy 用于 Ingress,因此 Ingress 服务可能容易遭到拒绝服务攻击。

该怎么做?

要修复这些漏洞,请将 Anthos on Bare Metal 集群升级到以下某个修补后的版本(发布时):

  • 1.6.3
  • 1.7.1

GCP-2021-003

发布日期:2021-04-19
参考编号CVE-2021-25735

GKE

说明 严重程度

Kubernetes 项目最近公布了新的安全漏洞 CVE-2021-25735,该安全漏洞会导致节点更新绕过验证准入网络钩子。

如果攻击者拥有足够的权限,并且验证准入网络钩子使用旧的 Node 对象属性(例如 Node.NodeSpec 中的字段)实现,则攻击者可以更新节点的属性,从而危害集群安全。GKE 和 Kubernetes 内置准入控制器强制执行的政策均不会受到影响,但我们建议客户检查他们已安装的任何其他准入网络钩子。

该怎么做?

如需修复此漏洞,请将 GKE 集群升级到以下经过修补的版本之一:

  • 1.18.17-gke.900
  • 1.19.9-gke.900
  • 1.20.5-gke.900

Anthos clusters on

说明 严重程度

Kubernetes 项目最近公布了新的安全漏洞 CVE-2021-25735,该安全漏洞会导致节点更新绕过验证准入网络钩子。

如果攻击者拥有足够的权限,并且验证准入网络钩子使用旧的 Node 对象属性(例如 Node.NodeSpec 中的字段)实现,则攻击者可以更新节点的属性,从而危害集群安全。GKE 和 Kubernetes 内置准入控制器强制执行的政策均不会受到影响,但我们建议客户检查他们已安装的任何其他准入网络钩子。

该怎么做?

即将推出的补丁程序版本将包含针对此漏洞的缓解措施。

Anthos clusters on

说明 严重程度

Kubernetes 项目最近公布了新的安全漏洞 CVE-2021-25735,该安全漏洞会导致节点更新绕过验证准入网络钩子。

如果攻击者拥有足够的权限,并且验证准入网络钩子使用旧的 Node 对象属性(例如 Node.NodeSpec 中的字段)实现,则攻击者可以更新节点的属性,从而危害集群安全。GKE 和 Kubernetes 内置准入控制器强制执行的政策均不会受到影响,但我们建议客户检查他们已安装的任何其他准入网络钩子。

该怎么做?

即将推出的补丁程序版本将包含针对此漏洞的缓解措施。

Anthos clusters on

说明 严重程度

Kubernetes 项目最近公布了新的安全漏洞 CVE-2021-25735,该安全漏洞会导致节点更新绕过验证准入网络钩子。

如果攻击者拥有足够的权限,并且验证准入网络钩子使用旧的 Node 对象属性(例如 Node.NodeSpec 中的字段)实现,则攻击者可以更新节点的属性,从而危害集群安全。GKE 和 Kubernetes 内置准入控制器强制执行的政策均不会受到影响,但我们建议客户检查他们已安装的任何其他准入网络钩子。

该怎么做?

即将推出的补丁程序版本将包含针对此漏洞的缓解措施。

GCP-2021-001

发布日期:2021-01-28
参考编号CVE-2021-3156

GKE

说明 严重程度

近期在 Linux 实用程序 sudo 中发现了一个漏洞(如 CVE-2021-3156 中所述),该漏洞可能会允许具有非特权本地 shell 的攻击者访问安装了 sudo 的系统,将其权限升级为系统 root 权限。

Google Kubernetes Engine (GKE) 集群不受此漏洞的影响:

  • 有权使用 SSH 连接到 GKE 节点的用户已被视为高权限用户,可以使用 sudo 获取 root 权限,这是设计使然。在这种情况下,该漏洞不会产生任何其他提权路径。
  • 大多数 GKE 系统容器都是通过未安装 shell 或 sudoDistroless 基础映像构建的。其他映像是通过不包含 sudo 的 debian 基础映像构建的。即使有 sudo,由于容器边界的存在,容器内部的 sudo 访问权限不会授予您访问主机的权限。

该怎么做?

由于 GKE 集群不受此漏洞的影响,因此无需采取进一步行动。

GKE 将定期在未来的版本中应用此漏洞的补丁程序。

Anthos clusters on

说明 严重程度

近期在 Linux 实用程序 sudo 中发现了一个漏洞(如 CVE-2021-3156 中所述),该漏洞可能会允许具有非特权本地 shell 的攻击者访问安装了 sudo 的系统,将其权限升级为系统 root 权限。

Anthos clusters on VMware 不受此漏洞的影响:

  • 有权使用 SSH 连接到 Anthos clusters on VMware 节点的用户已被视为高权限用户,可以使用 sudo 获取 root 权限,这是设计使然。在这种情况下,该漏洞不会产生任何其他提权路径。
  • 大多数 Anthos clusters on VMware 系统容器都是通过未安装 shell 或 sudoDistroless 基础映像构建的。其他映像是通过不包含 sudo 的 debian 基础映像构建的。即使有 sudo,由于容器边界的存在,容器内部的 sudo 访问权限不会授予您访问主机的权限。

该怎么做?

由于 Anthos clusters on VMware 集群不受此漏洞的影响,因此无需采取进一步行动。

Anthos clusters on VMware 将定期在未来的版本中应用此漏洞的补丁程序。

Anthos clusters on

说明 严重程度

近期在 Linux 实用程序 sudo 中发现了一个漏洞(如 CVE-2021-3156 中所述),该漏洞可能会允许具有非特权本地 shell 的攻击者访问安装了 sudo 的系统,将其权限升级为系统 root 权限。

Anthos clusters on AWS 不受此漏洞的影响:

  • 有权使用 SSH 连接到 Anthos clusters on AWS 节点的用户已被视为高权限用户,可以使用 sudo 获取 root 权限,这是设计使然。在这种情况下,该漏洞不会产生任何其他提权路径。
  • 大多数 Anthos clusters on AWS 系统容器都是通过未安装 shell 或 sudoDistroless 基础映像构建的。其他映像是通过不包含 sudo 的 debian 基础映像构建的。即使有 sudo,由于容器边界的存在,容器内部的 sudo 访问权限不会授予您访问主机的权限。

该怎么做?

由于 Anthos clusters on AWS 集群不受此漏洞的影响,因此无需采取进一步行动。

Anthos clusters on AWS 将定期在未来的版本中应用此漏洞的补丁程序。

Anthos clusters on

说明 严重程度

近期在 Linux 实用程序 sudo 中发现了一个漏洞(如 CVE-2021-3156 中所述),该漏洞可能会允许具有非特权本地 shell 的攻击者访问安装了 sudo 的系统,将其权限升级为系统 root 权限。

Anthos on Bare Metal 集群不受此漏洞的影响:

  • 有权使用 SSH 连接到 Anthos on Bare Metal 节点的用户已被视为高权限用户,可以使用 sudo 获取 root 权限,这是设计使然。在这种情况下,该漏洞不会产生任何其他提权路径。
  • 大多数 Anthos on Bare Metal 系统容器都是通过未安装 shell 或 sudoDistroless 基础映像构建的。其他映像是通过不包含 sudo 的 debian 基础映像构建的。即使有 sudo,由于容器边界的存在,容器内部的 sudo 访问权限不会授予您访问主机的权限。

该怎么做?

由于 Anthos on Bare Metal 集群不受此漏洞的影响,因此无需采取进一步行动。

Anthos on Bare Metal 将定期在未来的版本中应用此漏洞的补丁程序。

GCP-2020-015

发布日期:2020-12-07
参考编号CVE-2020-8554

GKE

说明 严重程度

Kubernetes 项目最近发现新的安全漏洞 CVE-2020-8554,它可能允许已获得创建 LoadBalancer 或 ClusterIP 类型的 Kubernetes Service 的权限的攻击者拦截来自集群中其他 pod 的网络流量。

此漏洞本身不会给予攻击者创建 Kubernetes 服务的权限。

所有 Google Kubernetes Engine (GKE) 集群都会受此漏洞的影响。

该怎么做?

Kubernetes 可能需要在未来版本中进行向后不兼容的设计更改,以解决该漏洞。

如果许多用户共享集群的访问权限并具有创建 Service 的权限(例如在一个多租户集群中),请考虑同时应用缓解措施。目前,最好的缓解方法是限制 ExternalIP 在集群中的使用。ExternalIP 不是常用功能。

通过以下任方法限制 ExternalIP 在集群中的使用:

  1. 将 Anthos 政策控制器或 Gatekeeper 与此限制条件模板结合使用,并加以应用。例如:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. 或者安装准入控制器以防止使用 ExternalIP。 Kubernetes 项目为此任务提供了准入控制器示例

Kubernetes 公告中所述,不会为 LoadBalancer 类型的 Service 的提供缓解措施,因为默认情况下,仅高权限用户和系统组件会被授予利用此漏洞所需的 container.services.updateStatus 权限

Anthos clusters on

说明 严重程度

Kubernetes 项目最近发现新的安全漏洞 CVE-2020-8554,它可能允许已获得创建 LoadBalancer 或 ClusterIP 类型的 Kubernetes Service 的权限的攻击者拦截来自集群中其他 pod 的网络流量。

此漏洞本身不会给予攻击者创建 Kubernetes 服务的权限。

所有 Anthos clusters on VMware 集群都会受到此漏洞的影响。

该怎么做?

Kubernetes 可能需要在未来版本中进行向后不兼容的设计更改,以解决该漏洞。

如果许多用户共享集群的访问权限并具有创建 Service 的权限(例如在一个多租户集群中),请考虑同时应用缓解措施。目前,最好的缓解方法是限制 ExternalIP 在集群中的使用。ExternalIP 不是常用功能。

通过以下任方法限制 ExternalIP 在集群中的使用:

  1. 将 Anthos 政策控制器或 Gatekeeper 与此限制条件模板结合使用,并加以应用。例如:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. 或者安装准入控制器以防止使用 ExternalIP。 Kubernetes 项目为此任务提供了准入控制器示例

Kubernetes 公告中所述,不会为 LoadBalancer 类型的 Service 的提供缓解措施,因为默认情况下,仅高权限用户和系统组件会被授予利用此漏洞所需的 container.services.updateStatus 权限

Anthos clusters on

说明 严重程度

Kubernetes 项目最近发现新的安全漏洞 CVE-2020-8554,它可能允许已获得创建 LoadBalancer 或 ClusterIP 类型的 Kubernetes Service 的权限的攻击者拦截来自集群中其他 pod 的网络流量。

此漏洞本身不会给予攻击者创建 Kubernetes 服务的权限。

所有 Anthos clusters on AWS 集群都会受到此漏洞的影响。

该怎么做?

Kubernetes 可能需要在未来版本中进行向后不兼容的设计更改,以解决该漏洞。

如果许多用户共享集群的访问权限并具有创建 Service 的权限(例如在一个多租户集群中),请考虑同时应用缓解措施。目前,最好的缓解方法是限制 ExternalIP 在集群中的使用。ExternalIP 不是常用功能。

通过以下任方法限制 ExternalIP 在集群中的使用:

  1. 将 Anthos 政策控制器或 Gatekeeper 与此限制条件模板结合使用,并加以应用。例如:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. 或者安装准入控制器以防止使用 ExternalIP。 Kubernetes 项目为此任务提供了准入控制器示例

Kubernetes 公告中所述,不会为 LoadBalancer 类型的 Service 的提供缓解措施,因为默认情况下,仅高权限用户和系统组件会被授予利用此漏洞所需的 container.services.updateStatus 权限

GCP-2020-014

发布日期:2020-10-20
参考编号CVE-2020-8563CVE-2020-8564CVE-2020-8565CVE-2020-8566

GKE

更新日期:2020-10-20

说明 严重程度

Kubernetes 项目最近发现了多个问题,这些问题导致在启用详细日志记录选项时 Secret 数据泄露。这些问题包括:

  • CVE-2020-8563:vSphere 提供商的 kube-controller-manager 日志中发生 Secret 泄露
  • CVE-2020-8584:当文件格式错误且日志级别大于等于 4 时,Docker 配置 Secret 发生泄露
  • CVE-2020-8565:当日志级别大于等于 9 时,Kubernetes 中 CVE-2019-11250 的不完整的修复程序导致日志中发生令牌泄露。由 GKE 安全发现。
  • CVE-2020-8566:当日志级别大于等于 4 时,日志中发生 Ceph RBD adminSecret 泄露

GKE 不受影响。

该怎么做?

由于 GKE 的默认详细日志记录级别,无需执行任何进一步操作。

Anthos clusters on

更新日期:2020-10-10

说明 严重程度

Kubernetes 项目最近发现了多个问题,这些问题导致在启用详细日志记录选项时 Secret 数据泄露。这些问题包括:

  • CVE-2020-8563:vSphere 提供商的 kube-controller-manager 日志中发生 Secret 泄露
  • CVE-2020-8584:当文件格式错误且日志级别大于等于 4 时,Docker 配置 Secret 发生泄露
  • CVE-2020-8565:当日志级别大于等于 9 时,Kubernetes 中 CVE-2019-11250 的不完整的修复程序导致日志中发生令牌泄露。由 GKE 安全发现。
  • CVE-2020-8566:当日志级别大于等于 4 时,日志中发生 Ceph RBD adminSecret 泄露

Anthos clusters on VMware 不受影响。

该怎么做?

由于 GKE 的默认详细日志记录级别,无需执行任何进一步操作。

Anthos clusters on

更新日期:2020-10-20

说明 严重程度

Kubernetes 项目最近发现了多个问题,这些问题导致在启用详细日志记录选项时 Secret 数据泄露。这些问题包括:

  • CVE-2020-8563:vSphere 提供商的 kube-controller-manager 日志中发生 Secret 泄露
  • CVE-2020-8584:当文件格式错误且日志级别大于等于 4 时,Docker 配置 Secret 发生泄露
  • CVE-2020-8565:当日志级别大于等于 9 时,Kubernetes 中 CVE-2019-11250 的不完整的修复程序导致日志中发生令牌泄露。由 GKE 安全发现。
  • CVE-2020-8566:当日志级别大于等于 4 时,日志中发生 Ceph RBD adminSecret 泄露

Anthos clusters on AWS 不受影响。

该怎么做?

由于 GKE 的默认详细日志记录级别,无需执行任何进一步操作。

GCP-2020-012

发布日期:2020-09-14
参考编号CVE-2020-14386

GKE

说明 严重程度

近期在 Linux 内核中发现了一个漏洞(如 CVE-2020-14386 中所述),该漏洞可能会允许容器逃逸,从而获得主机节点上的 root 权限。

所有 GKE 节点都会受到影响。在 GKE Sandbox 中运行的 pod 无法利用此漏洞。

该怎么做?

要修复此漏洞,请将控制层面和节点先后升级到下面列出的某个修补后的版本:

  • 1.14.10-gke.50
  • 1.15.12-gke.20
  • 1.16.13-gke.401
  • 1.17.9-gke.1504
  • 1.18.6-gke.3504

利用此漏洞需要 CAP_NET_RAW,但极少数容器通常需要 CAP_NET_RAW。默认情况下,应通过 PodSecurityPolicy 或 Policy Controller 阻止此功能和其他强大的功能:

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

漏洞 CVE-2020-14386,该漏洞允许具有 CAP_NET_RAW 的容器写入 1 到 10 个字节的内核内存,可能会使容器逃逸并获取对主机节点的 root 权限。此漏洞的严重级别评级为“高”。

Anthos clusters on

更新日期:2020-09-17

说明 严重程度

近期在 Linux 内核中发现了一个漏洞(如 CVE-2020-14386 中所述),该漏洞可能会允许容器逃逸,从而获得主机节点上的 root 权限。

所有 Anthos clusters on VMware 节点都会受到影响。

该怎么做?

要修复此漏洞,请将集群升级到修补后的版本。以下即将发布的 {gke_on_prem_name}} 版本将包含针对此漏洞的修补程序,在这些版本发布后,本公告会进行更新:

  • Anthos clusters on VMware 1.4.3 现已发布。
  • Anthos clusters on VMware 1.3.4 现已发布。

利用此漏洞需要 CAP_NET_RAW,但极少数容器通常需要 CAP_NET_RAW。默认情况下,应通过 PodSecurityPolicy 或 Policy Controller 阻止此功能和其他强大的功能:

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

漏洞 CVE-2020-14386,该漏洞允许具有 CAP_NET_RAW 的容器写入 1 到 10 个字节的内核内存,可能会使容器逃逸并获取对主机节点的 root 权限。此漏洞的严重级别评级为“高”。

Anthos clusters on

更新日期:2020-10-13

说明 严重程度

近期在 Linux 内核中发现了一个漏洞(如 CVE-2020-14386 中所述),该漏洞可能会允许容器逃逸,从而获得主机节点上的 root 权限。

所有 Anthos clusters on AWS 节点都会受到影响。

该怎么做?

要修复此漏洞,请将管理服务用户集群升级到修补后的版本。以下即将发布的 Anthos clusters on AWS 版本或更高版本将包含针对此漏洞的修补程序,在这些版本发布后,本公告会进行更新:

  • 1.5.0-gke.6
  • 1.4.3-gke.7

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

漏洞 CVE-2020-14386,该漏洞允许具有 CAP_NET_RAW 的容器写入 1 到 10 个字节的内核内存,可能会使容器逃逸并获取对主机节点的 root 权限。此漏洞的严重级别评级为“高”。

GCP-2020-011

发布日期:2020-07-24
参考编号CVE-2020-8558

GKE

说明 严重程度

最近在 Kubernetes 中发现了一个网络漏洞 CVE-2020-8558。服务有时会使用本地环回接口 (127.0.0.1) 与同一 pod 中运行的其他应用通信。利用此漏洞,有权访问集群网络的攻击者能够将流量发送到相邻 pod 和节点的环回接口。如果服务依赖于无法在其 pod 之外访问的环回接口,则攻击者可以利用这些服务。

要在 GKE 集群上利用此漏洞,攻击者需要拥有托管集群 VPC 的 Google Cloud 的网络管理员权限。此漏洞本身并不会授予攻击者网络管理员权限。因此,对于 GKE,此漏洞的严重级别分配为低。

该怎么做?

要修复此漏洞,请将集群的节点池升级到以下 GKE 版本(及更高版本):

  • 1.17.7-gke.0
  • 1.16.11-gke.0
  • 1.16.10-gke.11
  • 1.16.9-gke.14

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

此补丁程序修复了以下漏洞:CVE-2020-8558

Anthos clusters on

说明 严重程度

最近在 Kubernetes 中发现了一个网络漏洞 CVE-2020-8558。服务有时会使用本地环回接口 (127.0.0.1) 与同一 pod 中运行的其他应用通信。利用此漏洞,有权访问集群网络的攻击者能够将流量发送到相邻 pod 和节点的环回接口。如果服务依赖于无法在其 pod 之外访问的环回接口,则攻击者可以利用这些服务。

该怎么做?

如需修复此漏洞,请将您的集群升级到修补后的版本。以下即将发布的 Anthos clusters on VMware 版本或更高版本包含针对此漏洞的修补程序:

  • Anthos clusters on VMware 1.4.1

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

此补丁程序修复了以下漏洞:CVE-2020-8558

Anthos clusters on

说明 严重程度

最近在 Kubernetes 中发现了一个网络漏洞 CVE-2020-8558。服务有时会使用本地环回接口 (127.0.0.1) 与同一 pod 中运行的其他应用通信。利用此漏洞,有权访问集群网络的攻击者能够将流量发送到相邻 pod 和节点的环回接口。如果服务依赖于无法在其 pod 之外访问的环回接口,则攻击者可以利用这些服务。

在用户集群上利用此漏洞需要攻击者在集群中的 EC2 实例上停用源目标检查。这要求攻击者拥有对 EC2 实例上的 ModifyInstanceAttributeModifyNetworkInterfaceAttribute 的 AWS IAM 权限。因此,对于 Anthos clusters on AWS,此漏洞严重级别分配为“低”。

该怎么做?

如需修复此漏洞,请将您的集群升级到修补后的版本。以下即将发布的 Anthos clusters on AWS 版本或更高版本将包含针对此漏洞的修补程序:

  • Anthos clusters on AWS 1.4.1-gke.17

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

此补丁程序修复了以下漏洞:CVE-2020-8558

GCP-2020-009

发布日期:2020-07-15
参考编号CVE-2020-8559

GKE

说明 严重程度

最近在 Kubernetes 中发现了一个提权漏洞 CVE-2020-8559。利用此漏洞,已破解节点的攻击者能够在集群中的任何 pod 中执行命令。因此,攻击者可以使用已被破解的节点来破解其他节点并且可能读取信息,或者导致破坏性操作。

请注意,集群中的某个节点必须已被破解,攻击者才能利用此漏洞。此漏洞本身不会破解集群中的任何节点。

该怎么做?

将集群升级到修补后的版本。集群将在接下来的几周内自动升级,修补后的版本已在 2020 年 7 月 19 日之前提供,以加快手动升级计划速度。以下 GKE 控制层面版本或更新版本包含针对此漏洞的修复:

  • v1.14.10-gke.46
  • v1.15.12-gke.8
  • v1.16.9-gke.11
  • v1.16.10-gke.9
  • v1.16.11-gke.3+
  • v1.17.7-gke.6+

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

这些补丁程序解决了漏洞 CVE-2020-8559。此漏洞被评为 GKE 的中危漏洞,因为除了现有已遭破解的节点之外,攻击者还需要拥有集群、节点和工作负载的第一手信息,才能有效利用此攻击。此漏洞本身不会为攻击者提供已遭破解的节点。

Anthos clusters on

说明 严重程度

最近在 Kubernetes 中发现了一个提权漏洞 CVE-2020-8559。利用此漏洞,已破解节点的攻击者能够在集群中的任何 pod 中执行命令。因此,攻击者可以使用已被破解的节点来破解其他节点并且可能读取信息,或者导致破坏性操作。

请注意,集群中的某个节点必须已被破解,攻击者才能利用此漏洞。此漏洞本身不会破解集群中的任何节点。

该怎么做?

将集群升级到修补后的版本。以下即将发布的 Anthos clusters on VMware 版本或更高版本包含针对此漏洞的修补程序:

  • Anthos 1.3.3
  • Anthos 1.4.1

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

这些补丁程序解决了漏洞 CVE-2020-8559。此漏洞被评为 GKE 的中危漏洞,因为除了现有已遭破解的节点之外,攻击者还需要拥有集群、节点和工作负载的第一手信息,才能有效利用此攻击。此漏洞本身不会为攻击者提供已遭破解的节点。

Anthos clusters on

说明 严重程度

最近在 Kubernetes 中发现了一个提权漏洞 CVE-2020-8559。利用此漏洞,已破解节点的攻击者能够在集群中的任何 pod 中执行命令。因此,攻击者可以使用已被破解的节点来破解其他节点并且可能读取信息,或者导致破坏性操作。

请注意,集群中的某个节点必须已被破解,攻击者才能利用此漏洞。此漏洞本身不会破解集群中的任何节点。

该怎么做?

Anthos clusters on AWS GA 1.4.1 将于 2020 年 7 月底发布,该版本及更高版本包含针对此漏洞的补丁程序。如果您使用的是以前的版本,请下载新版本的 anthos-gke 命令行工具,并重新创建管理和用户集群。

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

这些补丁程序解决了漏洞 CVE-2020-8559。此漏洞被评为 GKE 的中危漏洞,因为除了现有已遭破解的节点之外,攻击者还需要拥有集群、节点和工作负载的第一手信息,才能有效利用此攻击。此漏洞本身不会为攻击者提供已遭破解的节点。

GCP-2020-007

发布日期:2020-06-01
参考编号CVE-2020-8555

GKE

说明 严重程度

技术人员最近在 Kubernetes 中发现了服务器端请求伪造 (SSRF) 漏洞 CVE-2020-8555,该漏洞允许某些授权用户从控制层面主机网络泄露高达 500 字节的敏感信息。Google Kubernetes Engine (GKE) 控制层面会使用 Kubernetes 中的控制器,因此会受到此漏洞的影响。 我们建议您将控制层面升级到最新的补丁程序版本,具体说明如下所述。节点不需要升级。

该怎么做?

大多数客户无需执行任何额外操作。绝大多数集群已在运行修补版本。 以下 GKE 版本或更高版本包含针对此漏洞的修补程序:
  • 1.14.7-gke.39
  • 1.14.8-gke.32
  • 1.14.9-gke.17
  • 1.14.10-gke.12
  • 1.15.7-gke.17
  • 1.16.4-gke.21
  • 1.17.0-gke.0

使用发布渠道的集群已在采取了缓解措施的控制层面版本上运行。

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

这些补丁程序解决了漏洞 CVE-2020-8555。此漏洞被评为 GKE 的中危漏洞,由于各种控制层面安全强化措施的实施而很难被利用。

有权创建内置了卷类型(GlusterFS、Quobyte、StorageFS、ScaleIO)的 Pod 的攻击者或有权创建 StorageClass 的攻击者可以使 kube-controller-manager 发出 GET 请求或 POST 请求,而无需通过主实例的主机网络控制请求正文。这些卷类型在 GKE 上很少使用,因此重新使用这些卷类型可能是一个有用的检测信号。

如果与重新向攻击者泄露 GET/POST 结果的方法结合使用(例如通过日志),则可能会导致敏感信息被披露。我们更新了相关的存储驱动程序,以消除发生此类泄露的可能性。

Anthos clusters on

说明 严重程度

技术人员最近在 Kubernetes 中发现了服务器端请求伪造 (SSRF) 漏洞 CVE-2020-8555,该漏洞允许某些授权用户从控制层面主机网络泄露高达 500 字节的敏感信息。Google Kubernetes Engine (GKE) 控制层面会使用 Kubernetes 中的控制器,因此会受到此漏洞的影响。 我们建议您将控制层面升级到最新的补丁程序版本,具体说明如下所述。节点不需要升级。

该怎么做?

以下 Anthos clusters on VMware (GKE On-Prem) 版本或更高版本包含针对此漏洞的修补程序:

  • Anthos 1.3.0

如果您使用的是以前的版本,请将现有集群升级到包含该修复的版本。

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

这些补丁程序解决了漏洞 CVE-2020-8555。此漏洞被评为 GKE 的中危漏洞,由于各种控制层面安全强化措施的实施而很难被利用。

有权创建内置了卷类型(GlusterFS、Quobyte、StorageFS、ScaleIO)的 Pod 的攻击者或有权创建 StorageClass 的攻击者可以使 kube-controller-manager 发出 GET 请求或 POST 请求,而无需通过主实例的主机网络控制请求正文。这些卷类型在 GKE 上很少使用,因此重新使用这些卷类型可能是一个有用的检测信号。

如果与重新向攻击者泄露 GET/POST 结果的方法结合使用(例如通过日志),则可能会导致敏感信息被披露。我们更新了相关的存储驱动程序,以消除发生此类泄露的可能性。

Anthos clusters on

说明 严重程度

技术人员最近在 Kubernetes 中发现了服务器端请求伪造 (SSRF) 漏洞 CVE-2020-8555,该漏洞允许某些授权用户从控制层面主机网络泄露高达 500 字节的敏感信息。Google Kubernetes Engine (GKE) 控制层面会使用 Kubernetes 中的控制器,因此会受到此漏洞的影响。 我们建议您将控制层面升级到最新的补丁程序版本,具体说明如下所述。节点不需要升级。

该怎么做?

Anthos clusters on AWS (GKE on AWS) v0.2.0 或更高版本已包含针对此漏洞的补丁程序。如果您使用的是以前的版本,请下载新版本的 anthos-gke 命令行工具,并重新创建管理集群和用户集群。

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

这些补丁程序解决了漏洞 CVE-2020-8555。此漏洞被评为 GKE 的中危漏洞,由于各种控制层面安全强化措施的实施而很难被利用。

有权创建内置了卷类型(GlusterFS、Quobyte、StorageFS、ScaleIO)的 Pod 的攻击者或有权创建 StorageClass 的攻击者可以使 kube-controller-manager 发出 GET 请求或 POST 请求,而无需通过主实例的主机网络控制请求正文。这些卷类型在 GKE 上很少使用,因此重新使用这些卷类型可能是一个有用的检测信号。

如果与重新向攻击者泄露 GET/POST 结果的方法结合使用(例如通过日志),则可能会导致敏感信息被披露。我们更新了相关的存储驱动程序,以消除发生此类泄露的可能性。

GCP-2020-006

发布日期:2020-06-01
参考编号Kubernetes 问题 91507

GKE

说明 严重程度

Kubernetes 披露了一个漏洞,该漏洞允许特权容器将节点流量重定向至其他容器。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。所有 Google Kubernetes Engine (GKE) 节点都会受到此漏洞的影响,我们建议您升级到最新的补丁程序版本,具体说明如下所述。

该怎么做?

要解决此漏洞,请升级您的控制层面,然后将您的节点升级为下面列出的一个修补版本。使用发布渠道的集群已同时在控制平面和节点上运行修补版本:
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

通常,很少有容器需要 CAP_NET_RAW。默认情况下,应该通过 PodSecurityPolicyAnthos 政策控制器阻止此功能和其他强大的功能:

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

Kubernetes 问题 91507 中所述的漏洞 CAP_NET_RAW 功能(包含在默认容器功能集中)会在节点上恶意配置 IPv6 堆栈,并将节点流量重定向至攻击者控制的容器。这样一来,攻击者就可以拦截/修改源自或发送至该节点的流量。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。

Anthos clusters on

说明 严重程度

Kubernetes 披露了一个漏洞,该漏洞允许特权容器将节点流量重定向至其他容器。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。所有 Google Kubernetes Engine (GKE) 节点都会受到此漏洞的影响,我们建议您升级到最新的补丁程序版本,具体说明如下所述。

该怎么做?

如需针对 Anthos clusters on VMware (GKE On-Prem) 修复此漏洞,请升级集群到以下版本或更高版本:
  • Anthos 1.3.2

通常,很少有容器需要 CAP_NET_RAW。默认情况下,应通过 Anthos 政策控制器或更新 pod 规范来阻止此功能和其他强大的功能:

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

Kubernetes 问题 91507 中所述的漏洞 CAP_NET_RAW 功能(包含在默认容器功能集中)会在节点上恶意配置 IPv6 堆栈,并将节点流量重定向至攻击者控制的容器。这样一来,攻击者就可以拦截/修改源自或发送至该节点的流量。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。

Anthos clusters on

说明 严重程度

Kubernetes 披露了一个漏洞,该漏洞允许特权容器将节点流量重定向至其他容器。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。所有 Google Kubernetes Engine (GKE) 节点都会受到此漏洞的影响,我们建议您升级到最新的补丁程序版本,具体说明如下所述。

该怎么做?

下载以下版本或更高版本的 anthos-gke 命令行工具,然后重新创建管理集群和用户集群:

  • aws-0.2.1-gke.7

通常,很少有容器需要 CAP_NET_RAW。默认情况下,应通过 Anthos 政策控制器或更新 pod 规范来阻止此功能和其他强大的功能:

可以使用以下方法之一从容器中删除 CAP_NET_RAW 功能:

  • 使用 PodSecurityPolicy 强制阻止这些功能,例如:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • 或者将 Policy Controller 或 Gatekeeper 与此限制条件模板结合使用,并加以应用,例如:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • 或者更新您的 Pod 规范:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

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

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

Kubernetes 问题 91507 中所述的漏洞 CAP_NET_RAW 功能(包含在默认容器功能集中)会在节点上恶意配置 IPv6 堆栈,并将节点流量重定向至攻击者控制的容器。这样一来,攻击者就可以拦截/修改源自或发送至该节点的流量。此攻击无法读取或修改双向 TLS/SSH 流量(例如 kubelet 与 API 服务器之间)或来自使用 mTLS 的应用的流量。

GCP-2020-005

发布日期:2020-05-07
更新日期:2020-05-07
参考编号CVE-2020-8835

GKE

说明 严重程度

近期在 Linux 内核中发现了一个漏洞(如 CVE-2020-8835 中所述),该漏洞允许容器逃逸,从而获得主机节点上的 root 权限。

运行 GKE 1.16 或 1.17 版本的 Google Kubernetes Engine (GKE) Ubuntu 节点均受此漏洞影响,我们建议您按照下文详述的方法,尽快升级到最新补丁程序版本。

运行 Container-Optimized OS 的节点不受影响。在 Anthos clusters on VMware 上运行的节点不受影响。

该怎么做?

大多数客户无需执行任何额外操作。只有使用 GKE 1.16 或 1.17 版本且运行 Ubuntu 的节点会受到影响。

若要升级节点,您必须先将主实例升级到最新版本。Kubernetes 1.16.8-gke.12、1.17.4-gke.10 及更新的版本中提供了该补丁程序。在版本说明中可以跟踪这些补丁程序的提供情况。

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

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

CVE-2020-8835 描述了 Linux 内核 5.5.0 版本及更新版本中的一个漏洞,该漏洞允许恶意容器(只需极少的用户互动,执行一次 exec 即可触发)读写内核内存,从而获得主机节点上的 root 级代码执行权限。此漏洞的严重级别分级为“高”。

GCP-2020-004

发布日期:2020-05-07
更新日期:2020-05-07
参考编号CVE-2019-11254

Anthos clusters on

说明 严重程度

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

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

该怎么做?

我们建议您尽快将集群升级为包含此漏洞修复的补丁程序版本。

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

  • Anthos 1.3.0(运行 Kubernetes 1.15.7-gke.32 版)

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

该补丁程序修复了以下拒绝服务攻击 (DoS) 漏洞:

CVE-2019-11254

GCP-2020-003

发布日期:2020-03-31
更新日期:2020-03-31
参考编号CVE-2019-11254

GKE

说明 严重程度

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

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

该怎么做?

建议您将集群升级为包含针对此漏洞的修补程序的版本。

包含此修补程序的版本如下所示:

  • 1.13.12-gke.29
  • 1.14.9-gke.27
  • 1.14.10-gke.24
  • 1.15.9-gke.20
  • 1.16.6-gke.1

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

该补丁程序修复了以下拒绝服务攻击 (DoS) 漏洞:

CVE-2019-11254

GCP-2020-002

发布日期:2020-03-23
更新日期:2020-03-23
参考编号CVE-2020-8551CVE-2020-8552

GKE

说明 严重程度

Kubernetes 披露了两个拒绝服务攻击漏洞,一个影响 API 服务器,另一个影响 Kubelet。如需了解详情,请参见 Kubernetes 问题 8937789378

该怎么做?

所有 GKE 用户均已受到针对 CVE-2020-8551 的保护,唯一有风险的情况就是不受信任的用户能从集群的内部网络中发送请求。使用主授权网络可针对 CVE-2020-8552 提供额外的缓解措施。

何时会推出针对这些漏洞的补丁程序?

针对 CVE-2020-8551 的补丁程序要求进行节点升级。下面列出了将包含缓解措施的补丁程序版本:

  • 1.15.10-gke.*
  • 1.16.7-gke.*

针对 CVE-2020-8552 的补丁程序需要进行主节点升级。下面列出了将包含缓解措施的补丁程序版本:

  • 1.14.10-gke.32
  • 1.15.10-gke.*
  • 1.16.7-gke.*

2020 年 1 月 21 日

发布日期:2020-01-21
更新日期:2020-01-24
参考编号CVE-2019-11254

GKE

说明 严重程度

2020 年 1 月 24 日更新:我们正在推出修补版本,此过程将在 2020 年 1 月 25 日完成。


Microsoft 披露了 Windows Crypto API 及其对椭圆曲线签名的验证中的一个漏洞。如需了解详情,请参阅 Microsoft 披露信息

我该怎么做?

大多数客户无需执行任何额外操作。只有运行 Windows Server 的节点会受影响。

对使用 Windows Server 节点的客户而言,节点以及在这些节点上运行的容器化工作负载都必须更新到修补版本以缓解此漏洞。

如需更新容器,请执行以下操作:

使用 Microsoft 的最新基础容器映像重新构建容器,请选择上次更新时间为 2020 年 1 月 14 日或更晚日期的 servercorenanoserver 标记。

如需更新节点,请执行以下操作:

我们正在推出修补版本,此过程将在 2020 年 1 月 24 日完成。

届时,您可以将节点升级为 GKE 修补版本,也可以随时使用 Windows 更新手动部署最新的 Windows 补丁程序。

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

  • 1.14.7-gke.40
  • 1.14.8-gke.33
  • 1.14.9-gke.23
  • 1.14.10-gke.17
  • 1.15.7-gke.23
  • 1.16.4-gke.22

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

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

CVE-2020-0601 - 此漏洞又称为 Windows Crypto API 仿冒漏洞,攻击者可以利用此漏洞将恶意可执行文件伪装成受信任的程序,或者发动中间人攻击并解密与受影响软件的 TLS 连接相关的机密信息。

NVD 基本得分:8.1(高)

已归档的安全公告

如需查看 2020 年之前的安全公告,请参阅安全公告归档