Security bulletins

All security bulletins for Anthos clusters on VMware (GKE on-prem) are described in this topic.

Vulnerabilities are often kept secret under embargos until affected parties have had a chance to address them. In these cases, Anthos clusters on VMware's Release notes will refer to "security updates" until the embargo has been lifted. At that point the notes will be updated to reflect the vulnerability the patch addressed.

To get the latest security bulletins delivered to you, add the URL of this page to your feed reader.

GCP-2020-015

Published: 2020-12-07
Description Severity Notes

The Kubernetes project recently discovered a new security vulnerability, CVE-2020-8554, that might allow an attacker who has obtained permissions to create a Kubernetes Service of type LoadBalancer or ClusterIP to intercept network traffic originating from other Pods in the cluster.

This vulnerability by itself does not give an attacker permissions to create a Kubernetes Service.

All Anthos clusters on VMware are affected by this vulnerability.

What should I do?

Kubernetes might need to make backwards incompatible design changes in a future version to address the vulnerability.

If many users share access to your cluster with permissions to create Services, such as in a multi-tenant cluster, consider applying a mitigation in the meantime. For now, the best approach for mitigation is to restrict the use of ExternalIPs in a cluster. ExternalIPs are not a commonly used feature.

Restrict the use of ExternalIPs in a cluster with one of the following methods:
  1. Use Anthos Policy Controller or Gatekeeper with this constraint template and apply it. For example: 
    # 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. Or install an admission controller to prevent the use of ExternalIPs. The Kubernetes project has provided a sample admission controller for this task.

As mentioned in the Kubernetes announcement, no mitigation is provided for Services of type LoadBalancer because, by default, only highly privileged users and system components are granted the container.services.updateStatus permission which is required to leverage this vulnerability.

Medium

CVE-2020-8554

GCP-2020-014

Published: 2020-10-20
Updated: 2020-10-10
Description Severity Notes

The Kubernetes project recently discovered several issues that allow for the exposure of secret data when verbose logging options are enabled. The issues are:

  • CVE-2020-8563: Secret leaks in logs for vSphere Provider kube-controller-manager
  • CVE-2020-8564: Docker config secrets leaked when file is malformed and loglevel >= 4
  • CVE-2020-8565: Incomplete fix for CVE-2019-11250 in Kubernetes allows for token leak in logs when logLevel >= 9. Discovered by GKE Security.
  • CVE-2020-8566: Ceph RBD adminSecrets exposed in logs when loglevel >= 4

GKE on-prem is not affected.

What should I do?

No further action is required due to the default verbosity logging levels of GKE.

None

GCP-2020-012

Published: 2020-09-14
Updated: 2020-09-17
Description Severity Notes

A vulnerability was recently discovered in the Linux kernel, described in CVE-2020-14386, that may allow container escape to obtain root privileges on the host node.

All Anthos clusters on VMware nodes are affected.

What should I do?

To fix this vulnerability, upgrade your cluster to a patched version. The following upcoming Anthos clusters on VMware versions will contain the fix for this vulnerability, and this bulletin will be updated when they are available:

  • Anthos clusters on VMware 1.4.3, now available.
  • Anthos clusters on VMware 1.3.4, now available.

Exploiting this vulnerability requires CAP_NET_RAW, but very few containers typically require CAP_NET_RAW. This and other powerful capabilities should be blocked by default through PodSecurityPolicy or Policy Controller:

Drop the CAP_NET_RAW capability from containers with one of the following methods:

  • Enforce blocking these capabilities with PodSecurityPolicy, for example: 
          # 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
  • Or by using Policy Controller or Gatekeeper with this constraint template and applying it, for example: 
          # 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"
  • Or by updating your Pod specs: 
          # 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

What vulnerability is addressed by this patch?

The patch mitigates the following vulnerability:

The vulnerability CVE-2020-14386, which allows containers with CAP_NET_RAW
to write 1 to 10 bytes of kernel memory, and possibly escape the container and obtain root privileges on the host node. This is rated as a High severity vulnerability.

High

CVE-2020-14386

GCP-2020-011

Published: 2020-07-24
Description Severity Notes

A networking vulnerability, CVE-2020-8558, was recently discovered in Kubernetes. Services sometimes communicate with other applications running inside the same Pod using the local loopback interface (127.0.0.1). This vulnerability allows an attacker with access to the cluster's network to send traffic to the loopback interface of adjacent Pods and nodes. Services that rely on the loopback interface not being accessible outside their Pod could be exploited.

What should I do?

To fix this vulnerability, upgrade your cluster to a patched version. The following Anthos clusters on VMware versions or newer contain the fix for this vulnerability:

  • Anthos clusters on VMware 1.4.1
  • Anthos clusters on VMware 1.3.5

What vulnerability is addressed by this patch?

This patch fixes the following vulnerability: CVE-2020-8558.

Medium

CVE-2020-8558

GCP-2020-009

Published: 2020-07-15
Description Severity Notes

A privilege escalation vulnerability, CVE-2020-8559, was recently discovered in Kubernetes. This vulnerability allows an attacker that has already compromised a node to execute a command in any Pod in the cluster. The attacker can thereby use the already compromised node to compromise other nodes and potentially read information, or cause destructive actions.

Note that for an attacker to exploit this vulnerability, a node in your cluster must have already been compromised. This vulnerability, by itself, will not compromise any nodes in your cluster.

What should I do?

Upgrade your cluster to a patched version. The following upcoming Anthos clusters on VMware versions or newer contain the fix for this vulnerability:

  • Anthos 1.3.3
  • Anthos 1.4.1

What vulnerability is addressed by this patch?

These patches mitigate vulnerability CVE-2020-8559. This is rated as a Medium vulnerability for GKE, as it requires the attacker to have first hand information about the cluster, nodes, and workloads to effectively leverage this attack in addition to an existing compromised node. This vulnerability by itself will not provide an attacker with a compromised node.

Medium

CVE-2020-8559

GCP-2020-007

Published: 2020-06-01
Description Severity Notes

Server Side Request Forgery (SSRF) vulnerability, CVE-2020-8555, was recently discovered in Kubernetes, allowing certain authorized users to leak up to 500 bytes of sensitive information from the control plane host network. The Google Kubernetes Engine (GKE) control plane uses controllers from Kubernetes and is thus affected by this vulnerability. We recommend that you upgrade the control plane to the latest patch version, as we detail below. A node upgrade is not required.

What should I do?

The following Anthos clusters on VMware (GKE on-prem) versions or newer contain the fix for this vulnerability:

  • Anthos 1.3.0

If you are using a previous version, upgrade your existing cluster to a version containing the fix.

What vulnerability is addressed by this patch?

These patches mitigate vulnerability CVE-2020-8555. This is rated as a Medium vulnerability for GKE as it was difficult to exploit due to various control plane hardening measures.

An attacker with permissions to create a Pod with certain built-in Volume types (GlusterFS, Quobyte, StorageFS, ScaleIO) or permissions to create a StorageClass can cause kube-controller-manager to make GET requests or POST requests without an attacker controlled request body from the master's host network. These volume types are rarely used on GKE, so new use of these volume types may be a useful detection signal.

Combined with a means to leak the results of the GET/POST back to the attacker, such as through logs, this can lead to disclosure of sensitive information. We have updated the storage drivers in question to remove the potential for such leaks.

Medium

CVE-2020-8555

GCP-2020-006

Published: 2020-06-01
Description Severity Notes

Kubernetes has disclosed a vulnerability that allows a privileged container to redirect node traffic to another container. Mutual TLS/SSH traffic, such as between the kubelet and API server or traffic from applications using mTLS cannot be read or modified by this attack. All Google Kubernetes Engine (GKE) nodes are affected by this vulnerability, and we recommend that you upgrade to the latest patch version, as we detail below.

What should I do?

To mitigate this vulnerability for Anthos clusters on VMware (GKE on-prem), upgrade your clusters to the following version or newer:
  • Anthos 1.3.2

Very few containers typically require CAP_NET_RAW. This and other powerful capabilities should be blocked by default through Anthos Policy Controller or by updating your Pod specs:

Drop the CAP_NET_RAW capability from containers with one of the following methods:

  • Enforce blocking these capabilities with PodSecurityPolicy, for example: 
          # 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
  • Or by using Policy Controller or Gatekeeper with this constraint template and applying it, for example: 
          # 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"
  • Or by updating your Pod specs: 
          # 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

What vulnerability is addressed by this patch?

The patch mitigate the following vulnerability:

The vulnerability described in Kubernetes issue 91507 CAP_NET_RAW capability (which is included in the default container capability set) to maliciously configure the IPv6 stack on the node and redirect node traffic to the attacker controlled container. This will allow the attacker to intercept/modify traffic originating from or destined for the node. Mutual TLS/SSH traffic, such as between the kubelet and API server or traffic from applications using mTLS cannot be read or modified by this attack.

Medium

Kubernetes issue 91507

GCP-2020-004

Description Severity Notes

A vulnerability was recently discovered in Kubernetes, described in CVE-2019-11254, which allows any user authorized to make POST requests to execute a remote Denial-of-Service attack on a Kubernetes API server. The Kubernetes Product Security Committee (PSC) released additional information on this vulnerability which can be found here.

You can mitigate this vulnerability by limiting which clients have network access to your Kubernetes API servers.

What should I do?

We recommend that you upgrade your clusters to patch versions containing the fix for this vulnerability as soon as they are available.

The patch versions which contain the fix are listed below:

  • Anthos 1.3.0, which runs Kubernetes version 1.15.7-gke.32

What vulnerabilities are addressed by this patch?

The patch fixes the following Denial-of-Service (DoS) vulnerability:

CVE-2019-11254.

Medium

CVE-2019-11254

October 16, 2019

Description Severity Notes

A vulnerability was recently discovered in Kubernetes, described in CVE-2019-11253, which allows any user authorized to make POST requests to execute a remote Denial-of-Service attack on a Kubernetes API server. The Kubernetes Product Security Committee (PSC) released additional information on this vulnerability which can be found here.

You can mitigate this vulnerability by limiting which clients have network access to your Kubernetes API servers.

What should I do?

We recommend that you upgrade your clusters to a patch version containing the fix as soon as they are available.

The patch versions which will contain the fix are listed below:

  • Anthos 1.1.1, which runs Kubernetes version 1.13.7-gke.30
What vulnerability is addressed by this patch?

The patch mitigates the following vulnerability: CVE-2019-11253.

High

CVE-2019-11253

August 23, 2019

Description Severity Notes

We recently discovered and mitigated a vulnerability where the RBAC proxy used for securing monitoring endpoints did not correctly authorize users. As a result, metrics from certain components are available to unauthorized users from within the internal cluster network. The following components were affected:

  • etcd
  • etcd-events
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • node-exporter
  • kube-state-metrics
  • prometheus
  • alertmanager
What should I do?

We recommend that you upgrade your clusters to version 1.0.2-gke.3, which includes the patch for this vulnerability, as soon as possible.

Medium

Anthos clusters on VMware releases

August 22, 2019

Description Severity Notes

Kubernetes recently discovered a vulnerability, CVE-2019-11247, which allows cluster-scoped custom resource instances to be acted on as if they were namespaced objects existing in all Namespaces. This means user and service accounts with only namespace-level RBAC permissions can interact with cluster-scoped custom resources. Exploiting this vulnerability requires the attacker to have privileges to access the resource in any namespace.

What should I do?

We recommend that you upgrade your clusters to version 1.0.2-gke.3, which includes the patch for this vulnerability, as soon as possible.

What vulnerability is addressed by this patch?

The patch mitigates the following vulnerability: CVE-2019-11247.

Medium

CVE-2019-11247