安全公告

我们可能会不时发布与 Kubernetes Engine 相关的安全公告。Google Kubernetes Engine 的所有安全公告都会在此处列出。

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

订阅 GKE 安全公告。 订阅

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

2019 年 2 月 11 日 (Go)

说明 严重级别 备注

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

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)均会将此信息写入日志文件。

这些令牌拥有以下权限:


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 '&#123&#123(index .secrets 0).name&#125&#125' | 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 统称为“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 节点池会受到这两个漏洞的影响。

修补版本

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

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 版本中。请稍后查看此处了解详情。

2018 年 5 月 21 日

说明 严重级别 备注

最近在 Linux 内核中发现了多个漏洞,这些漏洞可能会允许无特权的进程提升其权限或开展拒绝服务攻击(通过内核崩溃)。这些 CVE 标识为 CVE-2018-1000199CVE-2018-8897CVE-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-1002101CVE-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 博文

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Kubernetes Engine