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.

For more information on how Google manages security vulnerabilities and patches for GKE and Anthos, see Security patching.

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

GCP-2021-024

Published: 2021-10-21
Reference: CVE-2021-25742

GKE

Description Severity

A security issue was discovered in the Kubernetes ingress-nginx controller, CVE-2021-25742. Ingress-nginx custom snippets allows retrieval of ingress-nginx service account tokens and secrets across all namespaces.

What should I do?

This security issue does not impact your GKE cluster infrastructure or any Anthos environments cluster infrastructure. If you use ingress-nginx in your workload deployments, you should be aware of this security issue. See ingress-nginx Issue 7837 for more details.

None

Anthos clusters on

Description Severity

A security issue was discovered in the Kubernetes ingress-nginx controller, CVE-2021-25742. Ingress-nginx custom snippets allows retrieval of ingress-nginx service account tokens and secrets across all namespaces.

What should I do?

This security issue does not impact your GKE cluster infrastructure or any Anthos environments cluster infrastructure. If you use ingress-nginx in your workload deployments, you should be aware of this security issue. See ingress-nginx Issue 7837 for more details.

None

Anthos clusters on

Description Severity

A security issue was discovered in the Kubernetes ingress-nginx controller, CVE-2021-25742. Ingress-nginx custom snippets allows retrieval of ingress-nginx service account tokens and secrets across all namespaces.

What should I do?

This security issue does not impact your GKE cluster infrastructure or any Anthos environments cluster infrastructure. If you use ingress-nginx in your workload deployments, you should be aware of this security issue. See ingress-nginx Issue 7837 for more details.

None

Anthos clusters on

Description Severity

A security issue was discovered in the Kubernetes ingress-nginx controller, CVE-2021-25742. Ingress-nginx custom snippets allows retrieval of ingress-nginx service account tokens and secrets across all namespaces.

What should I do?

This security issue does not impact your GKE cluster infrastructure or any Anthos environments cluster infrastructure. If you use ingress-nginx in your workload deployments, you should be aware of this security issue. See ingress-nginx Issue 7837 for more details.

None

GCP-2021-019

Published: 2021-09-29

GKE

Description Severity

There is a known issue where updating a BackendConfig resource using the v1beta1 API that removes an active Google Cloud Armor security policy from its service.

Am I impacted?

If your BackendConfig has already been updated with the v1beta1 API, your Google Cloud Armor security policy might have been removed. To determine if this has happened, run the following command:

kubectl get backendconfigs -A -o json | \
jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
  • If the response returns output: your cluster is impacted by the issue. The output of this command returns a list of BackendConfig resources (<namespace>/<name>) that are affected by the issue.
  • If the output is empty: your BackendConfig has not been updated using the v1beta1 API since the issue has been introduced. Any future updates to your BackendConfig should only use v1.

This issue affects the following GKE versions:

  • 1.18.19-gke.1400 to 1.18.20-gke.5100 (exclusive)
  • 1.19.10-gke.700 to 1.19.14-gke.300 (exclusive)
  • 1.20.6-gke.700 to 1.20.9-gke.900 (exclusive)
  • 1.21 to 1.21.1-gke.2700 (exclusive)

If you do not configure Google Cloud Armor on your Ingress resources via the BackendConfig, then this issue does not affect your clusters.

What should I do?

Upgrade your GKE control plane to one of the following updated versions that patches this issue and allows v1beta1 BackendConfig resources to be used safely:

  • 1.21.1-gke.2700 and later
  • 1.20.9-gke.900 and later
  • 1.19.14-gke.300 and later
  • 1.18.20-gke.5100 and later

This issue can also be prevented by avoiding the deployment of v1beta1 BackendConfig resources. If you configure Google Cloud Armor on your Ingress resources via the BackendConfig and you've found that you're impacted through the steps above, re-enable Google Cloud Armor by pushing an update to your current BackendConfig resource with the cloud.google.com/v1 API version.

To prevent this issue, only make updates to your BackendConfig using the v1 BackendConfig API.

Since the v1 BackendConfig supports all the same fields as v1beta1 and makes no breaking changes, the API field can be updated transparently. To do so, replace the apiVersion field of any active BackendConfig manifest with cloud.google.com/v1 and do not use cloud.google.com/v1beta1.

The following sample manifest describes a BackendConfig resource that uses the v1API:

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

If you have CI/CD systems or tools which regularly update BackendConfig resources, ensure that you are using the cloud.google.com/v1 API group in those systems

Low

GCP-2021-022

Published: 2021-09-23

Anthos clusters on

Description Severity

A vulnerability has been discovered in the Anthos Identity Service (AIS) LDAP module of Anthos clusters on VMware versions 1.8 and 1.8.1 where a seed key used in generating keys is predictable. With this vulnerability, an authenticated user could add arbitrary claims and escalate privileges indefinitely.

Technical details

A recent addition to AIS code creates symmetric keys using golang's math/rand module, which is not suitable for security-sensitive code. The module is used in a way that will generate a predictable key. During identity verification, a secure token service (STS) key is generated that is subsequently encrypted with a symmetric key that is simple to derive.

What should I do?

This vulnerability only affects customers using AIS in Anthos clusters on VMware versions 1.8 and 1.8.1. For users of Anthos clusters on VMware 1.8, upgrade your clusters to the following version:

  • 1.8.2
High

GCP-2021-021

Published: 2021-09-22
Reference: CVE-2020-8561

GKE

Description Severity

A security vulnerability, CVE-2020-8561, has been discovered in Kubernetes where certain webhooks can be made to redirect kube-apiserver requests to private networks of that API server.

Technical details

With this vulnerability, actors who control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the API server. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This issue can be mitigated by changing certain parameters for the API server.

What should I do?

No action is required at this time.

Currently available versions of GKE and Anthos have implemented the following mitigations that protect against this type of attack:

  • The --profiling flag for kube-apiserver is set to false.
  • The kube-apiserver log level is set below 10.

What vulnerability is addressed by this patch?

CVE-2020-8561

Medium

Anthos clusters on

Description Severity

A security vulnerability, CVE-2020-8561, has been discovered in Kubernetes where certain webhooks can be made to redirect kube-apiserver requests to private networks of that API server.

Technical details

With this vulnerability, actors who control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the API server. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This issue can be mitigated by changing certain parameters for the API server.

What should I do?

No action is required at this time.

Currently available versions of GKE and Anthos have implemented the following mitigations that protect against this type of attack:

  • The --profiling flag for kube-apiserver is set to false.
  • The kube-apiserver log level is set below 10.

What vulnerability is addressed by this patch?

CVE-2020-8561

Medium

Anthos clusters on

Description Severity

A security vulnerability, CVE-2020-8561, has been discovered in Kubernetes where certain webhooks can be made to redirect kube-apiserver requests to private networks of that API server.

Technical details

With this vulnerability, actors who control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the API server. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This issue can be mitigated by changing certain parameters for the API server.

What should I do?

No action is required at this time.

Currently available versions of GKE and Anthos have implemented the following mitigations that protect against this type of attack:

  • The --profiling flag for kube-apiserver is set to false.
  • The kube-apiserver log level is set below 10.

What vulnerability is addressed by this patch?

CVE-2020-8561

Medium

Anthos clusters on

Description Severity

A security vulnerability, CVE-2020-8561, has been discovered in Kubernetes where certain webhooks can be made to redirect kube-apiserver requests to private networks of that API server.

Technical details

With this vulnerability, actors who control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the API server. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This issue can be mitigated by changing certain parameters for the API server.

What should I do?

No action is required at this time.

Currently available versions of GKE and Anthos have implemented the following mitigations that protect against this type of attack:

  • The --profiling flag for kube-apiserver is set to false.
  • The kube-apiserver log level is set below 10.

What vulnerability is addressed by this patch?

CVE-2020-8561

Medium

GCP-2021-018

Published: 2021-09-15
Updated: 2021-09-24
Reference: CVE-2021-25741

2021-09-24 update: Anthos clusters on bare metal bulletin updated with additional patched versions.

2021-09-20 update: Bulletins added for Anthos clusters on bare metal

2021-09-16 update: Bulletins added for Anthos clusters on VMware


GKE

Description Severity

A security issue was discovered in Kubernetes, CVE-2021-25741, where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

Technical details:

In CVE-2021-25741, the attacker can create a symbolic link from a mounted emptyDir to the root filesystem of the node ( / ), the kubelet will follow the symlink and mount the host root into the container.

What should I do?

We recommend you to upgrade your node pools to one of the following versions or above to take advantage of the latest patches:

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

The following versions also contain the fix:

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

Anthos clusters on

Description Severity

A security issue was discovered in Kubernetes, CVE-2021-25741, where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

Technical details:

In CVE-2021-25741, the attacker can create a symbolic link from a mounted emptyDir to the root filesystem of the node ( / ), the kubelet will follow the symlink and mount the host root into the container.

What should I do?

Updated 2021-09-24: Patched versions 1.8.3 and 1.7.4 are now available.

Updated 2021-09-17: Corrected the list of available versions that contain the patch.


The following versions of Anthos clusters on VMware have been updated with code to fix this vulnerability. Upgrade your admin clusters and user clusters to one of the following versions:

  • 1.8.3
  • 1.8.2
  • 1.7.4
  • 1.6.5
High

Anthos clusters on

Description Severity

A security issue was discovered in Kubernetes, CVE-2021-25741, where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

Technical details:

In CVE-2021-25741, the attacker can create a symbolic link from a mounted emptyDir to the root filesystem of the node ( / ), the kubelet will follow the symlink and mount the host root into the container.

What should I do?

2021-9-16 Update: Added list of supported gke-versions for AWSCluster and AWSNodePool objects.


The following versions of Anthos clusters on AWS have been updated with code to fix this vulnerability. It is recommended that you:

  • Upgrade your AWSManagementService, AWSCluster and AWSNodePool objects to the following version:
    • 1.8.2
  • Update the gke-version of your AWSCluster and AWSNodePool objects to one of the supported Kubernetes versions:
    • 1.17.17-gke.15800
    • 1.18.20-gke.4800
    • 1.19.14-gke.600
    • 1.20.10-gke.600
High

Anthos clusters on

Description Severity

A security issue was discovered in Kubernetes, CVE-2021-25741, where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

Technical details:

In CVE-2021-25741, the attacker can create a symbolic link from a mounted emptyDir to the root filesystem of the node ( / ), the kubelet will follow the symlink and mount the host root into the container.

What should I do?

The following versions of Anthos clusters on bare metal have been updated with code to fix this vulnerability. Upgrade your admin clusters and user clusters to one of the following versions:

  • 1.8.3
  • 1.7.4
High

GCP-2021-017

Published: 2021-09-01
Updated: 2021-09-23
Reference: CVE-2021-33909
CVE-2021-33910

GKE

Description Severity
2021-09-23 update:

Containers running inside of GKE Sandbox are unaffected by this vulnerability for attacks originating inside the container.


2021-09-15 update:

The following GKE versions address the vulnerabilities:

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

Two security vulnerabilities, CVE-2021-33909 and CVE-2021-33910, have been discovered in the Linux kernel that can lead to an OS crash or an escalation to root by an unprivileged user. This vulnerability affects all GKE node operating systems (COS and Ubuntu).

Technical details:

In CVE-2021-33909, the Linux kernel's filesystem layer does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root.
With CVE-2021-33910, systemd has a memory allocation with an excessive size value (involving strdupa and alloca for a pathname controlled by a local attacker) that results in an operating system crash.

What should I do?

The versions of Linux node images for the following versions of GKE have been updated with code to fix this vulnerability. Upgrade your clusters to one of the following versions:

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

Anthos clusters on

Description Severity

Two security vulnerabilities, CVE-2021-33909 and CVE-2021-33910, have been discovered in the Linux kernel that can lead to an OS crash or an escalation to root by an unprivileged user. This vulnerability affects all GKE node operating systems (COS and Ubuntu).

Technical details:

In CVE-2021-33909, the Linux kernel's filesystem layer does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root.
With CVE-2021-33910, systemd has a memory allocation with an excessive size value (involving strdupa and alloca for a pathname controlled by a local attacker) that results in an operating system crash.

What should I do?

The versions of Linux node images for Anthos clusters on AWS have been updated with code to fix this vulnerability. Upgrade your clusters to one of the following versions:

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

Anthos clusters on

Description Severity

Two security vulnerabilities, CVE-2021-33909 and CVE-2021-33910, have been discovered in the Linux kernel that can lead to an OS crash or an escalation to root by an unprivileged user. This vulnerability affects all GKE node operating systems (COS and Ubuntu).

Technical details:

In CVE-2021-33909, the Linux kernel's filesystem layer does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root.
With CVE-2021-33910, systemd has a memory allocation with an excessive size value (involving strdupa and alloca for a pathname controlled by a local attacker) that results in an operating system crash.

What should I do?

The versions of Linux and COS node images for Anthos clusters on VMware have been updated with code to fix this vulnerability. Upgrade your clusters to one of the following versions:

  • 1.9
  • 1.8.2
  • 1.7.3
  • 1.6.4 (Linux only)

See Version history--Kubernetes and node kernel versions.

High

GCP-2021-015

Published: 2021-07-13
Updated: 2021-07-15
Reference: CVE-2021-22555

GKE

Description Severity

A new security vulnerability, CVE-2021-22555, has been discovered where a malicious actor with CAP_NET_ADMIN privileges can potentially cause a container breakout to root on the host. This vulnerability affects all GKE clusters and Anthos clusters on VMware running Linux version 2.6.19 or later.

Technical details

In this attack, an out-of-bounds write in setsockopt in the netfilter subsystem in Linux can allow a heap corruption (and therefore denial of service) and escalation of privileges.

What should I do?

The following versions of Linux on GKE have been updated with code to fix this vulnerability. Upgrade your clusters to one of the following versions:

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

What vulnerability is addressed by this patch?

CVE-2021-22555

High

Anthos clusters on

Description Severity

A new security vulnerability, CVE-2021-22555, has been discovered where a malicious actor with CAP_NET_ADMIN privileges can potentially cause a container breakout to root on the host. This vulnerability affects all GKE clusters and Anthos clusters on VMware running Linux version 2.6.19 or later.

Technical details

In this attack, an out-of-bounds write in setsockopt in the netfilter subsystem in Linux can allow a heap corruption (and therefore denial of service) and escalation of privileges.

What should I do?

The following versions of Linux on Anthos clusters on VMware have been updated with code to fix this vulnerability. Upgrade your clusters to one of the following versions:

  • 1.8
  • 1.7.3
  • 1.6.4

What vulnerability is addressed by this patch?

CVE-2021-22555

High

GCP-2021-014

Published: 2021-07-05
Reference: CVE-2021-34527

GKE

Description Severity

Microsoft published a security bulletin on a Remote code execution (RCE) vulnerability, CVE-2021-34527, that affects the print spooler in Windows servers. The CERT Coordination Center (CERT/CC) published an update note on a related vulnerability, dubbed "PrintNightmare" that also affects Windows print spoolers - PrintNightmare, Critical Windows Print Spooler Vulnerability

What should I do?

No action is required. GKE Windows nodes do not contain the affected Spooler service as part of the base image, so GKE Windows deployments are not vulnerable to this attack.

What vulnerabilities are addressed by this bulletin?

High

GCP-2021-012

Published: 2021-07-01
Updated: 2021-07-09
Reference: CVE-2021-34824

GKE

Description Severity

What should I do?

The Istio project recently disclosed a new security vulnerability (CVE-2021-34824) affecting Istio. Istio contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces.

Technical details:

The Istio secure Gateway or workloads using the DestinationRule can load TLS private keys and certificates from Kubernetes secrets via the credentialName configuration. From Istio 1.8 and above, the secrets are read from istiod and conveyed to gateways and workloads via XDS.

Normally, a gateway or workload deployment is only able to access TLS certificates and private keys stored in the secret within its namespace. However, a bug in istiod allows a client authorized to access the Istio XDS API to retrieve any TLS certificate and private keys cached in istiod.

What should I do?

GKE clusters do not run Istio by default and, when enabled, use Istio version 1.6, which is not vulnerable to this attack. If you have installed or upgraded Istio on the cluster to Istio 1.8 or above, upgrade your Istio to the latest supported version.

High

Anthos clusters on

Description Severity

What should I do?

The Istio project recently disclosed a new security vulnerability (CVE-2021-34824) affecting Istio. Istio contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces.

Technical details:

The Istio secure Gateway or workloads using the DestinationRule can load TLS private keys and certificates from Kubernetes secrets via the credentialName configuration. From Istio 1.8 and above, the secrets are read from istiod and conveyed to gateways and workloads via XDS.

Normally, a gateway or workload deployment is only able to access TLS certificates and private keys stored in the secret within its namespace. However, a bug in istiod allows a client authorized to access the Istio XDS API to retrieve any TLS certificate and private keys cached in istiod.

What should I do?

Anthos clusters on VMware v1.6 and v1.7 are not vulnerable to this attack. Anthos clusters on VMware v1.8 are vulnerable.

If you are using Anthos clusters on VMware v1.8, upgrade to the following patched version or later:

  • 1.8.0-gke.25
High

Anthos clusters on

Description Severity

What should I do?

The Istio project recently disclosed a new security vulnerability (CVE-2021-34824) affecting Istio. Istio contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces.

Technical details:

The Istio secure Gateway or workloads using the DestinationRule can load TLS private keys and certificates from Kubernetes secrets via the credentialName configuration. From Istio 1.8 and above, the secrets are read from istiod and conveyed to gateways and workloads via XDS.

Normally, a gateway or workload deployment is only able to access TLS certificates and private keys stored in the secret within its namespace. However, a bug in istiod allows a client authorized to access the Istio XDS API to retrieve any TLS certificate and private keys cached in istiod. Clusters created or upgraded with Anthos clusters on bare metal v1.8.0 are impacted by this CVE.

What should I do?

Anthos v1.6 and 1.7 are not vulnerable to this attack. If you have v1.8.0 clusters, download and install the 1.8.1 version of bmctl and upgrade your clusters to the following patched version:

  • 1.8.1
High

GCP-2021-011

Published: 2021-06-04
Updated: 2021-10-19
Reference: CVE-2021-30465

2021-10-19 update: Added bulletins for Anthos clusters on VMware, Anthos clusters on AWS, and Anthos clusters on bare metal.

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.

Upgrade your GKE cluster to one of the following updated versions:

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

Medium

Anthos clusters on

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 Anthos clusters on VMware, 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 that fixes this vulnerability. Upgrade your Anthos clusters on VMware to one of the following versions:

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

Medium

Anthos clusters on

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.

Because this is an OS-level vulnerability, Anthos clusters on AWS are not vulnerable.

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?

Ensure that the OS version on which you are running Anthos clusters on AWS is upgraded to the latest OS version that has an updated runc package.

None

Anthos clusters on

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.

Because this is an OS-level vulnerability, Anthos clusters on bare metal are not vulnerable.

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?

Ensure that the OS version on which you are running Anthos on bare metal is upgraded to the latest OS version that has an updated runc package.

None

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.