Security bulletins

All security bulletins for the following products are described in this page:

  • Google Kubernetes Engine (GKE)
  • Anthos clusters on VMware (GKE on-prem)
  • Anthos clusters on AWS (GKE on AWS)
  • Anthos clusters on bare metal

Vulnerabilities are often kept secret under embargo until affected parties have had a chance to address them. In these cases, the product'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.

Use this XML feed to subscribe to security bulletins for this page. Subscribe

GCP-2021-011

Published: 2021-06-04
Reference: CVE-2021-30465

GKE

Description Severity

The security community recently disclosed a new security vulnerability (CVE-2021-30465) found in runc that has the potential to allow full access to a node filesystem.

For GKE, because exploiting this vulnerability requires the ability to create pods, we have rated the severity of this vulnerability at MEDIUM.

Technical details

The runc package is vulnerable to a symlink exchange attack when mounting a volume.

For this specific attack, a user can potentially exploit a race condition by starting multiple pods on a single node simultaneously, all of which share the same volume mount with a symlink.

If the attack succeeds, one of the pods will mount the node's filesystem with root permissions.

What should I do?

There is a newly released patch to runc (1.0.0-rc95) that fixes this vulnerability. GKE will be updated with this patch in an upcoming release.

Medium

GCP-2021-006

Published: 2021-05-11
Reference: CVE-2021-31920

GKE

Description Severity

The Istio project recently disclosed a new security vulnerability (CVE-2021-31920) affecting Istio.

Istio contains a remotely-exploitable vulnerability where an HTTP request with multiple slashes or escaped slash characters can bypass Istio authorization policy when path based authorization rules are used.

What should I do?

We strongly recommend that you update and reconfigure your GKE clusters. Please note it is important to complete both steps below to successfully resolve the vulnerability:

  1. Update your clusters: Please complete the following instructions to upgrade your clusters to the newest patch versions as soon as possible:
    • If you are using Istio on GKE 1.6:

      The newest patch release version is 1.6.14-gke.3. Please follow the upgrade instructions to upgrade your clusters to the newest version.

    • If you are using Istio on GKE 1.4:
    • Istio on GKE 1.4 releases are no longer supported by Istio and we do not backport CVE fixes to these versions. Please follow the Istio upgrade instructions to upgrade your clusters to 1.6, then follow the above instructions to get the newest version of Istio on GKE 1.6.

  2. Configure Istio:

    Once your clusters are patched, you must reconfigure Istio on GKE. Please refer to the security best practices guide to correctly configure your system.

High

GCP-2021-004

Published: 2021-05-06
Reference: CVE-2021-28683, CVE-2021-28682, CVE-2021-29258

GKE

Description Severity

The Envoy and Istio projects recently announced several new security vulnerabilities (CVE-2021-28683, CVE-2021-28682 and CVE-2021-29258), that could allow an attacker to crash Envoy.

GKE clusters do not run Istio by default and are not vulnerable. If Istio has been installed in a cluster and configured to expose services to the internet, those services may be vulnerable to denial of service.

What should I do?

To fix these vulnerabilities, upgrade your GKE control plane to one of the following patched versions:

  • 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
Medium

Anthos clusters on

Description Severity

The Envoy and Istio projects recently announced several new security vulnerabilities (CVE-2021-28683, CVE-2021-28682 and CVE-2021-29258), that could allow an attacker to crash Envoy.

Anthos clusters on VMware use Envoy by default for Ingress, so Ingress services may be vulnerable to denial of service.

What should I do?

To fix these vulnerabilities, upgrade your Anthos clusters on VMware to one of the following patched versions when released:

  • 1.5.4
  • 1.6.3
  • 1.7.1
Medium

Anthos clusters on

Updated: 2021-05-06

Description Severity

The Envoy and Istio projects recently announced several new security vulnerabilities (CVE-2021-28683, CVE-2021-28682 and CVE-2021-29258), that could allow an attacker to crash Envoy.

Anthos on bare metal uses Envoy by default for Ingress, so Ingress services may be vulnerable to denial of service.

What should I do?

To fix these vulnerabilities, upgrade your Anthos on bare metal cluster to one of the following patched versions when released:

  • 1.6.3
  • 1.7.1
Medium

GCP-2021-003

Published: 2021-04-19
Reference: CVE-2021-25735

GKE

Description Severity

The Kubernetes project recently announced a new security vulnerability, CVE-2021-25735, that could allow node updates to bypass a Validating Admission Webhook.

In a scenario where an attacker has sufficient privileges and where a Validating Admission Webhook is implemented that uses old Node object properties (for example fields in Node.NodeSpec), the attacker could update properties of a node that could lead to a cluster compromise. None of the policies enforced by GKE and Kubernetes built-in admission controllers are affected, but we recommend customers check any additional admission webhooks they have installed.

What should I do?

To fix this vulnerability, upgrade your GKE cluster to one of the following patched versions:

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

Anthos clusters on

Description Severity

The Kubernetes project recently announced a new security vulnerability, CVE-2021-25735, that could allow node updates to bypass a Validating Admission Webhook.

In a scenario where an attacker has sufficient privileges and where a Validating Admission Webhook is implemented that uses old Node object properties (for example fields in Node.NodeSpec), the attacker could update properties of a node that could lead to a cluster compromise. None of the policies enforced by GKE and Kubernetes built-in admission controllers are affected, but we recommend customers check any additional admission webhooks they have installed.

What should I do?

An upcoming patch version will include a mitigation for this vulnerability.

Medium

Anthos clusters on

Description Severity

The Kubernetes project recently announced a new security vulnerability, CVE-2021-25735, that could allow node updates to bypass a Validating Admission Webhook.

In a scenario where an attacker has sufficient privileges and where a Validating Admission Webhook is implemented that uses old Node object properties (for example fields in Node.NodeSpec), the attacker could update properties of a node that could lead to a cluster compromise. None of the policies enforced by GKE and Kubernetes built-in admission controllers are affected, but we recommend customers check any additional admission webhooks they have installed.

What should I do?

An upcoming patch version will include a mitigation for this vulnerability.

Medium

Anthos clusters on

Description Severity

The Kubernetes project recently announced a new security vulnerability, CVE-2021-25735, that could allow node updates to bypass a Validating Admission Webhook.

In a scenario where an attacker has sufficient privileges and where a Validating Admission Webhook is implemented that uses old Node object properties (for example fields in Node.NodeSpec), the attacker could update properties of a node that could lead to a cluster compromise. None of the policies enforced by GKE and Kubernetes built-in admission controllers are affected, but we recommend customers check any additional admission webhooks they have installed.

What should I do?

An upcoming patch version will include a mitigation for this vulnerability.

Medium

GCP-2021-001

Published: 2021-01-28
Reference: CVE-2021-3156

GKE

Description Severity

A vulnerability was recently discovered in the Linux utility sudo, described in CVE-2021-3156, that may allow an attacker with unprivileged local shell access on a system with sudo installed to escalate their privileges to root on the system.

Google Kubernetes Engine (GKE) clusters are not affected by this vulnerability:

  • Users who are authorized to SSH to GKE nodes are already considered highly privileged and can use sudo to obtain root privileges by design. The vulnerability does not yield any additional privilege escalation paths in this scenario.
  • Most GKE system containers are built from distroless base images which do not have a shell or sudo installed. Other images are built from a debian base image that doesn't contain sudo. Even if sudo was present, access to sudo inside the container does not give you access to the host due to the container boundary.

What should I do?

Because GKE clusters are not affected by this vulnerability, no further action is required.

GKE will have the patch for this vulnerability applied in a coming release at regular cadence.

None

Anthos clusters on

Description Severity

A vulnerability was recently discovered in the Linux utility sudo, described in CVE-2021-3156, that may allow an attacker with unprivileged local shell access on a system with sudo installed to escalate their privileges to root on the system.

Anthos clusters on VMware are not affected by this vulnerability:

  • Users who are authorized to SSH to Anthos clusters on VMware nodes are already considered highly privileged and can use sudo to obtain root privileges by design. The vulnerability does not yield any additional privilege escalation paths in this scenario.
  • Most Anthos clusters on VMware system containers are built from distroless base images which do not have a shell or sudo installed. Other images are built from a debian base image that doesn't contain sudo. Even if sudo was present, access to sudo inside the container does not give you access to the host due to the container boundary.

What should I do?

Because Anthos clusters on VMware clusters are not affected by this vulnerability, no further action is required.

Anthos clusters on VMware will have the patch for this vulnerability applied in a coming release at regular cadence.

None

Anthos clusters on

Description Severity

A vulnerability was recently discovered in the Linux utility sudo, described in CVE-2021-3156, that may allow an attacker with unprivileged local shell access on a system with sudo installed to escalate their privileges to root on the system.

Anthos clusters on AWS are not affected by this vulnerability:

  • Users who are authorized to SSH to Anthos clusters on AWS nodes are already considered highly privileged and can use sudo to obtain root privileges by design. The vulnerability does not yield any additional privilege escalation paths in this scenario.
  • Most Anthos clusters on AWS system containers are built from distroless base images which do not have a shell or sudo installed. Other images are built from a debian base image that doesn't contain sudo. Even if sudo was present, access to sudo inside the container does not give you access to the host due to the container boundary.

What should I do?

Because Anthos clusters on AWS clusters are not affected by this vulnerability, no further action is required.

Anthos clusters on AWS will have the patch for this vulnerability applied in a coming release at regular cadence.

None

Anthos clusters on

Description Severity

A vulnerability was recently discovered in the Linux utility sudo, described in CVE-2021-3156, that may allow an attacker with unprivileged local shell access on a system with sudo installed to escalate their privileges to root on the system.

Anthos on bare metal clusters are not affected by this vulnerability:

  • Users who are authorized to SSH to Anthos on bare metal nodes are already considered highly privileged and can use sudo to obtain root privileges by design. The vulnerability does not yield any additional privilege escalation paths in this scenario.
  • Most Anthos on bare metal system containers are built from distroless base images which do not have a shell or sudo installed. Other images are built from a debian base image that doesn't contain sudo. Even if sudo was present, access to sudo inside the container does not give you access to the host due to the container boundary.

What should I do?

Because Anthos on bare metal clusters are not affected by this vulnerability, no further action is required.

Anthos on bare metal will have the patch for this vulnerability applied in a coming release at regular cadence.

None

GCP-2020-015

Published: 2020-12-07
Reference: CVE-2020-8554

GKE

Description Severity

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 Google Kubernetes Engine (GKE) clusters 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

Anthos clusters on

Description Severity

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

Anthos clusters on

Description Severity

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 AWS 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

GCP-2020-014

Published: 2020-10-20
Reference: CVE-2020-8563, CVE-2020-8564, CVE-2020-8565, CVE-2020-8566

GKE

Updated: 2020-10-20

Description Severity

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 is not affected.

What should I do?

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

None

Anthos clusters on

Updated: 2020-10-10

Description Severity

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

Anthos clusters on VMware is not affected.

What should I do?

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

None

Anthos clusters on

Updated: 2020-10-20

Description Severity

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

Anthos clusters on AWS 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
Reference: CVE-2020-14386

GKE

Description Severity

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 GKE nodes are affected. Pods running in GKE Sandbox are not able to leverage this vulnerability.

What should I do?

To fix this vulnerability, upgrade your control plane, and then your nodes to one of the patched versions listed below:

  • 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

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

Anthos clusters on

Updated: 2020-09-17

Description Severity

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 {gke_on_prem_name}} 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

Anthos clusters on

Updated: 2020-10-13

Description Severity

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 AWS nodes are affected.

What should I do?

To fix this vulnerability, upgrade your management service and your user clusters to a patched version. The following upcoming Anthos clusters on AWS versions or newer will include the fix for this vulnerability, and this bulletin will be updated when they are available:

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

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

GCP-2020-011

Published: 2020-07-24
Reference: CVE-2020-8558

GKE

Description Severity

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.

Exploiting this vulnerability on GKE clusters requires an attacker to have network administrator privileges on the Google Cloud hosting the cluster's VPC. This vulnerability alone does not give an attacker network administrator privileges. For this reason, this vulnerability has been assigned a Low severity for GKE.

What should I do?

To fix this vulnerability, upgrade your cluster's node pools to the following GKE versions (and later):

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

What vulnerability is addressed by this patch?

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

Low

Anthos clusters on

Description Severity

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 upcoming Anthos clusters on VMware versions or newer contain the fix for this vulnerability:

  • Anthos clusters on VMware 1.4.1

What vulnerability is addressed by this patch?

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

Medium

Anthos clusters on

Description Severity

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.

Exploiting this vulnerability on user clusters requires an attacker to disable source destination checks on the EC2 instances in the cluster. This requires the attacker to have AWS IAM permissions for ModifyInstanceAttribute or ModifyNetworkInterfaceAttribute on the EC2 instances. For this reason, this vulnerability has been assigned a Low severity for Anthos clusters on AWS.

What should I do?

To fix this vulnerability, upgrade your cluster to a patched version. The following upcoming Anthos clusters on AWS versions or newer are expected to include the fix for this vulnerability:

  • Anthos clusters on AWS 1.4.1-gke.17

What vulnerability is addressed by this patch?

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

Low

GCP-2020-009

Published: 2020-07-15
Reference: CVE-2020-8559

GKE

Description Severity

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. Clusters will be auto-upgraded over the next weeks, and patched versions will be available by July 19, 2020 for an accelerated manual upgrade schedule. The following GKE control plane versions or newer contain the fix for this vulnerability:

  • 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+

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

Anthos clusters on

Description Severity

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

Anthos clusters on

Description Severity

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?

Anthos clusters on AWS GA (1.4.1, available end of July, 2020) or newer includes the patch for this vulnerability. If you are using a previous version, download a new version of the anthos-gke command line tool and recreate your management and user clusters.

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

GCP-2020-007

Published: 2020-06-01
Reference: CVE-2020-8555

GKE

Description Severity

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?

For most customers, no further action is required. The vast majority of clusters are already running a patched version. The following GKE versions or newer contain the fix for this vulnerability:
  • 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

Clusters using release channels are already on control plane versions with the mitigation.

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

Anthos clusters on

Description Severity

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

Anthos clusters on

Description Severity

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?

Anthos clusters on AWS (GKE on AWS) v0.2.0 or newer already includes the patch for this vulnerability. If you are using a previous version, download a new version of the anthos-gke command line tool and recreate your management and user clusters.

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

GCP-2020-006

Published: 2020-06-01
Reference: Kubernetes issue 91507

GKE

Description Severity

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, upgrade your control plane, and then your nodes to one of the patched versions listed below. Clusters on release channels are already running a patched version on both control plane and nodes:
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

Very few containers typically require CAP_NET_RAW. This and other powerful capabilities should be blocked by default through PodSecurityPolicy or Anthos 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 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

Anthos clusters on

Description Severity

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

Anthos clusters on

Description Severity

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?

Download the anthos-gke command line tool with the following version or newer and recreate your management and user clusters:

  • aws-0.2.1-gke.7

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

GCP-2020-005

Published: 2020-05-07
Updated: 2020-05-07
Reference: CVE-2020-8835

GKE

Description Severity

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

Google Kubernetes Engine (GKE) Ubuntu nodes running GKE 1.16 or 1.17 are affected by this vulnerability, and we recommend that you upgrade to the latest patch version as soon as possible, as we detail below.

Nodes running Container-Optimized OS are not affected. Nodes running on Anthos clusters on VMware are not affected.

What should I do?

For most customers, no further action is required. Only nodes running Ubuntu in GKE version 1.16 or 1.17 are affected.

In order to upgrade your nodes, you must first upgrade your master to the newest version. This patch will be available in Kubernetes 1.16.8-gke.12, 1.17.4-gke.10, and newer releases. Track the availability of these patches in the release notes.

What vulnerability is addressed by this patch?

The patch mitigates the following vulnerability:

CVE-2020-8835 describes a vulnerability in the Linux kernel version 5.5.0 and newer that allows a malicious container to (with minimal user interaction in the form of an exec) read and write kernel memory and thus gain root-level code execution on the host node. This is rated as a 'High' severity vulnerability.

High

GCP-2020-004

Published: 2020-05-07
Updated: 2020-05-07
Reference: CVE-2019-11254

Anthos clusters on

Description Severity

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

GCP-2020-003

Published: 2020-03-31
Updated: 2020-03-31
Reference: CVE-2019-11254

GKE

Description Severity

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.

GKE Clusters that use Master Authorized Networks and Private clusters with no public endpoint mitigate this vulnerability.

What should I do?

We recommend that you upgrade your cluster to a patch version containing the fix for this vulnerability.

The patch versions which contain the fix are listed below:

  • 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

What vulnerabilities are addressed by this patch?

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

CVE-2019-11254.

Medium

GCP-2020-002

Published: 2020-03-23
Updated: 2020-03-23
Reference: CVE-2020-8551, CVE-2020-8552

GKE

Description Severity

Kubernetes has disclosed two denial of service vulnerabilities, one impacting the API server, and the other impacting Kubelets. For more details, see the Kubernetes issues: 89377 and 89378.

What should I do?

All GKE users are protected from CVE-2020-8551 unless untrusted users can send requests within the cluster's internal network. Use of master authorized networks additionally mitigates against CVE-2020-8552.

When will these be patched?

Patches for CVE-2020-8551 require a node upgrade. The patch versions which will contain the mitigation are listed below:

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

Patches for CVE-2020-8552 require a master upgrade. The patch versions which will contain the mitigation are listed below:

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

January 21, 2020

Published: 2020-01-21
Updated: 2020-01-24
Reference: CVE-2019-11254

GKE

Description Severity

2020-01-24 Update: The process of making patched versions available is already underway and will be completed by January 25, 2020.


Microsoft has disclosed a vulnerability in the Windows Crypto API and its validation of elliptic curve signatures. For more information please see Microsoft's disclosure.

What should I do?

For most customers, no further action is required. Only nodes running Windows Server are impacted.

For customers who are using Windows Server nodes, both the nodes and the containerized workloads that run on those nodes must be updated to patched versions to mitigate this vulnerability.

To update the containers:

Rebuild your containers using Microsoft's latest base container images, selecting a servercore or nanoserver tag with a LastUpdated Time of 1/14/2020 or later.

To update the nodes:

The process of making patched versions available is already underway and will be completed by January 24, 2020.

You may either wait until that time and perform a node upgrade to a patched GKE version or you may use Windows Update to deploy the latest Windows patch manually at any time.

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

  • 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

What vulnerabilities are addressed by this patch?

The patch mitigates the following vulnerabilities:

CVE-2020-0601 - This vulnerability is also known as the Windows Crypto API Spoofing Vulnerability and could be exploited to make malicious executables appear trusted or allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on TLS connections to the affected software.

NVD Base Score: 8.1 (High)

Archived security bulletins

For security bulletins prior to 2020, see the Security bulletins archive.