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 on Azure
  • 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.

When GKE issues a security bulletin that directly correlates to your cluster configuration or version, we might send you a SecurityBulletinEvent cluster notification that provides information about the vulnerability and actions that you can take, if applicable. For information about setting up cluster notifications, refer to Cluster notifications.

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

GKE and Anthos platforms don't use components such as ingress-nginx and the CRI-O container runtime, and are unaffected by any vulnerabilities in those components. If you install components from other sources, refer to the security updates and patching advice of those components at the source.

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

GCP-2022-018

Published: 2022-08-01
Reference: CVE-2022-2327

GKE

Description Severity

A new vulnerability (CVE-2022-2327) has been discovered in the Linux kernel that can lead to local privilege escalation. This vulnerability allows an unprivileged user to achieve a full container breakout to root on the node.

Technical details

GKE clusters, including Autopilot clusters, with Container-Optimized OS (COS) using Linux Kernel version 5.10 are affected. GKE clusters using Ubuntu images or using GKE Sandbox are unaffected.

What should I do?

Upgrade your GKE clusters to a version that includes the fix. The Linux node images for COS have been updated along with GKE versions using those COS versions.

For security purposes, even if you have the node autoupgrade enabled, we recommend that you manually upgrade your node pools to one of the following GKE versions:

COS versions

  • 1.22.12-gke.300
  • 1.23.8-gke.1900
  • 1.24.2-gke.1900


A recent feature of release channels allows you to apply a patch without having to unsubscribe from a channel. This lets you upgrade your nodes to the patched version before that version becomes the default in your selected release channel.

What vulnerabilities are addressed by this patch?

With CVE-2022-2327, the Linux kernel in version 5.10 has a vulnerability in the io_uring subsystem where various requests are missing item types (flags). Using these requests without the proper item types specified can cause privilege escalation to root.
High

Anthos clusters on VMware

Description Severity

A new vulnerability (CVE-2022-2327) has been discovered in the Linux kernel that can lead to local privilege escalation. This vulnerability allows an unprivileged user to achieve a full container breakout to root on the node.

Clusters with a Container Optimized OS (COS) image using Anthos clusters on VMware versions 1.10, 1.11, and 1.12 are affected.

What should I do?

Versions of Anthos clusters on VMware that contain patches will be released soon. This security bulletin will be updated when the Anthos clusters on VMware versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-2327, the Linux kernel in version 5.10 has a vulnerability in the io_uring subsystem where various requests are missing item types (flags). Using these requests without the proper item types specified can cause privilege escalation to root.

High

Anthos clusters on AWS

Description Severity

A new vulnerability (CVE-2022-2327) has been discovered in the Linux kernel that can lead to local privilege escalation. This vulnerability allows an unprivileged user to achieve a full container breakout to root on the node.

What should I do?

Versions of Anthos clusters on AWS that contain patches will be released soon. This security bulletin will be updated when the Anthos clusters on AWS versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-2327, the Linux kernel in version 5.10 has a vulnerability in the io_uring subsystem where various requests are missing item types (flags). Using these requests without the proper item types specified can cause privilege escalation to root.

High

Anthos on Azure

Description Severity

A new vulnerability (CVE-2022-2327) has been discovered in the Linux kernel that can lead to local privilege escalation. This vulnerability allows an unprivileged user to achieve a full container breakout to root on the node.

What should I do?

Versions of Anthos on Azure that contain patches will be released soon. This security bulletin will be updated when the Anthos on Azure versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-2327, the Linux kernel in version 5.10 has a vulnerability in the io_uring subsystem where various requests are missing item types (flags). Using these requests without the proper item types specified can cause privilege escalation to root.

High

Anthos on bare metal

Description Severity

A new vulnerability (CVE-2022-2327) has been discovered in the Linux kernel that can lead to local privilege escalation. This vulnerability allows an unprivileged user to achieve a full container breakout to root on the node.

What should I do?

There is no action required. Anthos on bare metal is not affected by this CVE as it does not bundle an operating system in its distribution.

None

GCP-2022-017

Published: 2022-06-29
Updated: 2022-07-21
Reference: CVE-2022-1786

2022-07-21 Update: Updated information that Anthos clusters on VMware COS images are affected.

GKE

Description Severity

A new vulnerability (CVE-2022-1786) has been discovered in the Linux kernel versions 5.10 and 5.11. This vulnerability allows an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node. Only clusters that run Container-Optimized OS are affected. GKE Ubuntu versions use either version 5.4 or 5.15 of the kernel and are not affected.

What should I do?

The versions of Linux node images for Container-Optimized OS for the following versions of GKE have been updated with code to fix this vulnerability. For security purposes, even if you have node-autoupgrade enabled, we recommend that you manually upgrade your node pools to one of the following upcoming GKE versions:

  • 1.22.10-gke.600
  • 1.23.7-gke.1400
  • 1.24.1-gke.1400

A recent release channels feature allows you to apply a patch without having to unsubscribe from a channel. This lets you upgrade your nodes to the patched version before that version becomes the default in your selected release channel.

What vulnerabilities are addressed by this patch?

With CVE-2022-1786, a use-after-free flaw was found in the Linux kernel's io_uring subsystem. If a user sets up a ring with IORING_SETUP_IOPOLL with more than one task completing submissions on the ring, a local user can crash or escalate their privileges on the system.

High

Anthos clusters on VMware

Updated: 2022-07-14

Description Severity

A new vulnerability (CVE-2022-1786) has been discovered in the Linux kernel versions 5.10 and 5.11. This vulnerability allows an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node.

What should I do?

2022-07-21 Update: The following versions of Anthos clusters on VMware contain code that fixes this vulnerability.

COS
  • 1.10.5 or later
  • 1.11.2 or later
  • 1.12.0 or later

Ubuntu

There is no action required. Anthos clusters on VMware does not use the affected versions of the Linux kernel.

None

Anthos clusters on AWS

Description Severity

A new vulnerability (CVE-2022-1786) has been discovered in the Linux kernel versions 5.10 and 5.11. This vulnerability allows an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node.

What should I do?

There is no action required. Anthos clusters on AWS does not use the affected versions of the Linux kernel.

None

Anthos on Azure

Description Severity

A new vulnerability (CVE-2022-1786) has been discovered in the Linux kernel versions 5.10 and 5.11. This vulnerability allows an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node.

What should I do?

There is no action required. Anthos on Azure does not use the affected versions of the Linux kernel.

None

Anthos on bare metal

Description Severity

A new vulnerability (CVE-2022-1786) has been discovered in the Linux kernel versions 5.10 and 5.11. This vulnerability allows an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node.

What should I do?

There is no action required. Anthos on bare metal is not affected by this CVE as it does not bundle an operating system in its distribution.

None

GCP-2022-016

Published: 2022-06-23
Updated: 2022-07-29
Reference: CVE-2022-29581, CVE-2022-29582, CVE-2022-1116

2022-07-29 Update: Updated versions for Anthos clusters on VMware, Anthos clusters on AWS, and Anthos on Azure.

GKE

Updated: 2022-07-29

Description Severity

2022-07-29 update: Pods using GKE Sandbox are not vulnerable to these vulnerabilities.


Three new memory corruption vulnerabilities (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) have been discovered in the Linux kernel. These vulnerabilities allow an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node. All Linux clusters (Container-Optimized OS and Ubuntu) are affected.

What should I do?

The versions of Linux node images for both Container-Optimized OS and Ubuntu for the following versions of GKE have been updated with code to fix this vulnerability. For security purposes, even if you have node auto-upgrade enabled, we recommend that you manually upgrade your node pools to one of the following GKE versions:

  • Container-Optimized OS:
    • 1.19.16-gke.13800
    • 1.20.15-gke.8000
    • 1.21.12-gke.1500
    • 1.22.9-gke.1300
    • 1.23.6-gke.1500
    • 1.24.1-gke.1400
  • Ubuntu:
    • 1.20.15-gke.9600
    • 1.21.13-gke.900
    • 1.22.10-gke.600
    • 1.23.7-gke.1400
    • 1.24.1-gke.1400

A recent feature of release channels allows you to apply a patch without having to unsubscribe from a channel. This lets you upgrade your nodes to the patched version before that version becomes the default in your selected release channel.

What vulnerabilities are addressed by this patch?

With CVE-2022-29582, the Linux kernel in versions prior to 5.17.3 has a use-after-free due to a race condition in io_uring timeouts.

CVE-2022-29581 and CVE-2022-1116 are vulnerabilities where a local attacker can cause memory corruption in io_uring or net/sched in the Linux kernel to escalate privileges to root.

High

Anthos clusters on VMware

Updated: 2022-07-29

Description Severity

2022-07-29 Update: The following versions of Anthos clusters on VMware contain code that fixes these vulnerabilities.

  • 1.9.7 or later
  • 1.10.5 or later
  • 1.11.2 or later
  • 1.12.0 or later


Three new memory corruption vulnerabilities (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) have been discovered in the Linux kernel. These vulnerabilities allow an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node. These vulnerabilities affect Anthos clusters on VMware v1.9 and later for Container-Optimized OS and Ubuntu images.

What should I do?

Versions of Anthos clusters on VMware that contain patches will be released soon. This security bulletin will be updated when the Anthos clusters on VMware versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-29582, the Linux kernel in versions prior to 5.17.3 has a use-after-free due to a race condition in io_uring timeouts.

CVE-2022-29581 and CVE-2022-1116 are vulnerabilities where a local attacker can cause memory corruption in io_uring or net/sched in the Linux kernel to escalate privileges to root.

High

Anthos clusters on AWS

Updated: 2022-07-29

Description Severity

2022-07-29 Update: Update: The following current and previous generation versions of Anthos clusters on AWS have been updated with code to fix these vulnerabilities. We recommend that you upgrade your nodes to one of the following Anthos clusters on AWS versions:

Current generation:

  • 1.23.7-gke.1300
  • 1.22.10-gke.1500
  • 1.21.11-gke.1900
Previous generation:
  • 1.23.7-gke.1500
  • 1.22.10-gke.1500
  • 1.21.13-gke.1600

Three new memory corruption vulnerabilities (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) have been discovered in the Linux kernel. These vulnerabilities allow an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node. These vulnerabilities affect all versions of Anthos clusters on AWS.

What should I do?

Versions of Anthos clusters on AWS that contain patches will be released soon. This security bulletin will be updated when the Anthos clusters on AWS versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-29582, the Linux kernel in versions prior to 5.17.3 has a use-after-free due to a race condition in io_uring timeouts.

CVE-2022-29581 and CVE-2022-1116 are vulnerabilities where a local attacker can cause memory corruption in io_uring or net/sched in the Linux kernel to escalate privileges to root.

High

Anthos on Azure

Description Severity

2022-07-29 Update: Update: The following versions of Anthos on Azure have been updated with code to fix these vulnerabilities. We recommend that you upgrade your nodes to one of the following Anthos on Azure versions:

  • 1.23.7-gke.1300
  • 1.22.10-gke.1500
  • 1.21.11-gke.1900


Three new memory corruption vulnerabilities (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) have been discovered in the Linux kernel. These vulnerabilities allow an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node. These vulnerabilities affect all versions of Anthos on Azure.

What should I do?

Versions of Anthos on Azure that contain patches will be released soon. This security bulletin will be updated when the Anthos on Azure versions are available for download.

What vulnerabilities are addressed by this patch?

With CVE-2022-29582, the Linux kernel in versions prior to 5.17.3 has a use-after-free due to a race condition in io_uring timeouts.

CVE-2022-29581 and CVE-2022-1116 are vulnerabilities where a local attacker can cause memory corruption in io_uring or net/sched in the Linux kernel to escalate privileges to root.

High

Anthos on bare metal

Description Severity

Three new memory corruption vulnerabilities (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) have been discovered in the Linux kernel. These vulnerabilities allow an unprivileged user with local access to the cluster to achieve a full container breakout to root on the node.

What should I do?

There is no action required. Anthos on bare metal is not affected by this vulnerability as it does not bundle an operating system in its distribution.

None

GCP-2022-014

Published: 2022-04-26
Updated: 2022-05-12

2022-05-12 Update: Updated patch versions for Anthos clusters on AWS and Anthos on Azure.

Reference: CVE-2022-1055, CVE-2022-27666

GKE

Description Severity

Two security vulnerabilities, CVE-2022-1055 and CVE-2022-27666 have been discovered in the Linux kernel. Each can lead to a local attacker being able to perform a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all GKE node operating systems (Container-Optimized OS and Ubuntu).

Technical details

In CVE-2022-1055, an attacker can exploit use-after-free in tc_new_tfilter() which allows a local attacker in the container to escalate privileges to root on node.

In CVE-2022-27666, buffer overflow in esp/esp6_output_head allows a local attacker in the container to escalate privileges to root on the node.

What should I do?

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

  • 1.19.16-gke.11000 and later
  • 1.20.15-gke.5200 and later
  • 1.21.11-gke.1100 and later
  • 1.22.8-gke.200 and later
  • 1.23.5-gke.1500 and later

What vulnerabilities are addressed by this patch?

High

Anthos clusters on VMware

Description Severity

Two security vulnerabilities, CVE-2022-1055 and CVE-2022-27666 have been discovered in the Linux kernel. Each can lead to a local attacker being able to perform a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all GKE node operating systems (Container-Optimized OS and Ubuntu).

Technical details

In CVE-2022-1055, an attacker can exploit use-after-free in tc_new_tfilter() which allows a local attacker in the container to escalate privileges to root on node.

In CVE-2022-27666, buffer overflow in esp/esp6_output_head allows a local attacker in the container to escalate privileges to root on the node.

What should I do?

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

  • 1.9.6 (upcoming)
  • 1.10.3
  • 1.11.0 (upcoming)

What vulnerabilities are addressed by this patch?

High

Anthos clusters on AWS

Updated: 2022-05-12

Description Severity

Two security vulnerabilities, CVE-2022-1055 and CVE-2022-27666 have been discovered in the Linux kernel. Each can lead to a local attacker being able to perform a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all GKE node operating systems (Container-Optimized OS and Ubuntu).

Technical details

In CVE-2022-1055, an attacker can exploit use-after-free in tc_new_tfilter() which allows a local attacker in the container to escalate privileges to root on node.

In CVE-2022-27666, buffer overflow in esp/esp6_output_head allows a local attacker in the container to escalate privileges to root on the node.

What should I do?

2022-05-12 Update: The following current and previous generation versions of Anthos clusters on AWS have been updated with code to fix these vulnerabilities. We recommend that you upgrade your nodes to one of the following Anthos clusters on AWS versions:

Current generation
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300
Previous generation
  • 1.20.15-gke.5200
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Upgrade your cluster to a patched version. Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerabilities are addressed by this patch?

High

Anthos on Azure

Updated: 2022-05-12

Description Severity

Two security vulnerabilities, CVE-2022-1055 and CVE-2022-27666 have been discovered in the Linux kernel. Each can lead to a local attacker being able to perform a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all GKE node operating systems (Container-Optimized OS and Ubuntu).

Technical details

In CVE-2022-1055, an attacker can exploit use-after-free in tc_new_tfilter() which allows a local attacker in the container to escalate privileges to root on node.

In CVE-2022-27666, buffer overflow in esp/esp6_output_head allows a local attacker in the container to escalate privileges to root on the node.

What should I do?

2022-05-12 Update: The following versions of Anthos on Azure have been updated with code to fix these vulnerabilities. We recommend that you upgrade your nodes to one of the following Anthos on Azure versions:

  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Upgrade your cluster to a patched version. Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerabilities are addressed by this patch?

High

Anthos on bare metal

Description Severity

Two security vulnerabilities, CVE-2022-1055 and CVE-2022-27666 have been discovered in the Linux kernel. Each can lead to a local attacker being able to perform a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all GKE node operating systems (Container-Optimized OS and Ubuntu).

Technical details

In CVE-2022-1055, an attacker can exploit use-after-free in tc_new_tfilter() which allows a local attacker in the container to escalate privileges to root on node.

In CVE-2022-27666, buffer overflow in esp/esp6_output_head allows a local attacker in the container to escalate privileges to root on the node.

What should I do?

There is no action required. Anthos on bare metal is not affected by this CVE as it does not include Linux as part of its package. You should ensure that the node images you use are updated to versions that contain the fix for CVE-2022-1055 and CVE-2022-27666.

What vulnerabilities are addressed by this patch?

High

GCP-2022-013

Published: 2022-04-11
Updated: 2022-04-20
Reference: CVE-2022-23648
2022-04-22 Update: Updated patch versions for Anthos on bare metal and Anthos clusters on VMware.

GKE

Description Severity

A security vulnerability, CVE-2022-23648, has been discovered in containerd's handling of path traversal in the OCI image volume specification. Containers launched through containerd's CRI implementation with a specially-crafted image configuration could gain full read access to arbitrary files and directories on the host.

This vulnerability may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy). This vulnerability affects all GKE node operating systems (Container-Optimized OS and Ubuntu) which use containerd by default. All GKE, Autopilot, and GKE Sandbox nodes are affected.

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. For security purposes, even if you have node-autoupgrade enabled, we recommend that you manually upgrade your nodes to one of the following GKE versions:

  • 1.19.16-gke.9400
  • 1.20.15-gke.3600
  • 1.21.10-gke.1500
  • 1.22.7-gke.1500
  • 1.23.4-gke.1500

A recent feature of release channels allows you to apply a patch without having to unsubscribe from a channel. This lets you secure your nodes until the new version becomes the default for your specific release channel.

Medium

Anthos clusters on VMware

Updated: 2022-04-22

Description Severity

A security vulnerability, CVE-2022-23648, has been discovered in containerd's handling of path traversal in the OCI image volume specification. Containers launched through containerd's CRI implementation with a specially-crafted image configuration could gain full read access to arbitrary files and directories on the host.

This vulnerability may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy). This vulnerability affects all Anthos clusters on VMware with stackdriver enabled, which uses containerd. Anthos clusters on VMware versions 1.8, 1.9, and 1.10 are affected

What should I do?

2022-04-22 Update: The following versions of Anthos clusters on VMware contain code that fixes this vulnerability.

  • 1.9.5 or later
  • 1.10.3 or later
  • 1.11.0 or later

The following versions of Anthos clusters on VMware have been updated with code to fix this vulnerability. We recommend that you upgrade your nodes to one of the following Anthos clusters on VMware versions:

  • 1.8.8 or later
  • 1.9.5 or later
  • 1.10.2 or later

This CVE can be mitigated by setting IgnoreImageDefinedVolumes to true.

Medium

Anthos clusters on AWS

Description Severity

A security vulnerability, CVE-2022-23648, has been discovered in containerd's handling of path traversal in the OCI image volume specification. Containers launched through containerd's CRI implementation with a specially-crafted image configuration could gain full read access to arbitrary files and directories on the host.

This vulnerability may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy). All Anthos clusters on AWS versions are affected.

What should I do?

The following versions of Anthos clusters on AWS have been updated with code to fix this vulnerability. We recommend that you upgrade your nodes to one of the following Anthos clusters on AWS versions.

Anthos clusters on AWS (current generation)
  • Version 1.22: 1.22.8-gke.200
  • Version 1.21: 1.21.11-gke.100
Anthos clusters on AWS (previous generation)
  • Version 1.22: 1.22.8-gke.300
  • Version 1.21: 1.21.11-gke.100
  • Version 1.20: 1.20.15-gke.2200

This CVE can be mitigated by setting IgnoreImageDefinedVolumes to true.

Medium

Anthos on Azure

Description Severity

A security vulnerability, CVE-2022-23648, has been discovered in containerd's handling of path traversal in the OCI image volume specification. Containers launched through containerd's CRI implementation with a specially-crafted image configuration could gain full read access to arbitrary files and directories on the host.

This vulnerability may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy). All Anthos on Azure versions are affected.

What should I do?

The following versions of Anthos on Azure have been updated with code to fix this vulnerability. We recommend that you upgrade your nodes as follows:

  • Version 1.22: 1.22.8-gke.200
  • Version 1.21: 1.21.11-gke.100

This CVE can be mitigated by setting IgnoreImageDefinedVolumes to true.

Medium

Anthos on bare metal

Updated: 2022-04-22

Description Severity

A security vulnerability, CVE-2022-23648, has been discovered in containerd's handling of path traversal in the OCI image volume specification. Containers launched through containerd's CRI implementation with a specially-crafted image configuration could gain full read access to arbitrary files and directories on the host.

This vulnerability may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy). This vulnerability affects all Anthos on bare metal which use containerd. Anthos on bare metal versions 1.8, 1.9, and 1.10 are affected

What should I do?

2022-04-22 Update: The following versions of Anthos on bare metal contain code that fixes this vulnerability.

  • 1.8.9 or later
  • 1.9.6 or later
  • 1.10.3 or later
  • 1.11.0 or later

The following versions of Anthos on bare metal have been updated with code to fix this vulnerability. We recommend that you upgrade your nodes to one of the following Anthos on bare metal versions:

  • 1.8.8 or later
  • 1.9.5 or later
  • 1.10.2 or later

This CVE can be mitigated by setting IgnoreImageDefinedVolumes to true.

Medium

GCP-2022-012

Published: 2022-04-07
Reference: CVE-2022-0847

GKE

Description Severity

A security vulnerability, CVE-2022-0847, has been discovered in the Linux kernel version 5.8 and later that can potentially escalate container privileges to root. This vulnerability affects all GKE node pool versions v1.22 and later that use Container-Optimized OS images (Container-Optimized OS 93 and later). GKE node pools that use the Ubuntu OS are not affected.

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. For security purposes, even if you have node-autoupgrade enabled, we recommend that you manually upgrade your node pools to one of the following GKE versions:

  • 1.22.7-gke.1500 and later
  • 1.23.4-gke.1600 and later

A recent feature of release channels allows you to apply a patch version of other release channels without having to unsubscribe from a channel. This lets you secure your nodes until the new version becomes the default for your release specific channel.

What vulnerabilities are addressed by this patch?

CVE-2022-0847 relates to the PIPE_BUF_FLAG_CAN_MERGE flag that was introduced in version 5.8 of the Linux kernel. In this vulnerability, the "flags" member of the new pipe buffer structure was lacking proper initialization in the Linux kernel. An unprivileged local attacker can use this flaw to write to pages in the page cache backed by read only files and escalate their privileges.

New versions of Container-Optimized OS that fix this issue have been integrated into the updated node pool versions of GKE.

High

Anthos clusters on VMware

Description Severity

A security vulnerability, CVE-2022-0847, has been discovered in the Linux kernel version 5.8 and later that can potentially escalate privileges to root. This vulnerability affects Anthos clusters on VMware v1.10 for Container-Optimized OS images. Currently, Anthos clusters on VMware with Ubuntu is on kernel version 5.4 and is not vulnerable to this attack.

What should I do?

The versions of Linux node images for the following versions of Anthos clusters on VMware have been updated with code to fix this vulnerability. We recommend that you upgrade your admin and user clusters to the following Anthos clusters on VMware version:

  • 1.10.3

What vulnerabilities are addressed by this patch?

CVE-2022-0847 relates to the PIPE_BUF_FLAG_CAN_MERGE flag that was introduced in version 5.8 of the Linux kernel. In this vulnerability, the "flags" member of the new pipe buffer structure was lacking proper initialization in the Linux kernel. An unprivileged local attacker can use this flaw to write to pages in the page cache backed by read only files and escalate their privileges.

New versions of Container-Optimized OS that fix this issue have been integrated into the updated versions of Anthos clusters on VMware.

High

Anthos clusters on AWS

Description Severity

A security vulnerability, CVE-2022-0847, has been discovered in the Linux kernel version 5.8 and later that can potentially escalate privileges to root.

This vulnerability affects managed clusters of Anthos clusters on AWS v1.21 and clusters running on Anthos clusters on AWS (previous generation) v1.19, v1.20, v1.21, which use Ubuntu.

What should I do?

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

For managed Anthos clusters on AWS, we recommend that you upgrade your user clusters and nodepool to one of the following versions:

  • 1.21.11-gke.100

For k-lite Anthos clusters on AWS, we recommend that you upgrade your AWSManagementService, AWSCluster and AWSNodePool objects to the following version:

  • 1.21.11-gke.100
  • 1.20.15-gke.2200

What vulnerabilities are addressed by this patch?

CVE-2022-0847 relates to the PIPE_BUF_FLAG_CAN_MERGE flag that was introduced in version 5.8 of the Linux kernel. In this vulnerability, the "flags" member of the new pipe buffer structure was lacking proper initialization in the Linux kernel. An unprivileged local attacker can use this flaw to write to pages in the page cache backed by read only files and escalate their privileges.

High

Anthos on Azure

Description Severity

A security vulnerability, CVE-2022-0847, has been discovered in the Linux kernel version 5.8 and later that can potentially escalate privileges to root. This vulnerability affects managed clusters of Anthos on Azure v1.21 which use Ubuntu.

What should I do?

The versions of Linux node images for the following versions of Anthos on Azure have been updated with code to fix this vulnerability. We recommend that you upgrade your user clusters and nodepool to the following version:

  • 1.21.11-gke.100

What vulnerabilities are addressed by this patch?

CVE-2022-0847 relates to the PIPE_BUF_FLAG_CAN_MERGE flag that was introduced in version 5.8 of the Linux kernel. In this vulnerability, the "flags" member of the new pipe buffer structure was lacking proper initialization in the Linux kernel. An unprivileged local attacker can use this flaw to write to pages in the page cache backed by read only files and escalate their privileges.

High

Anthos on bare metal

Description Severity

A security vulnerability, CVE-2022-0847, has been discovered in the Linux kernel version 5.8 and later that can potentially escalate privileges to root.

What should I do?

There is no action required. Anthos on bare metal is not affected by this CVE as it does not include Linux as part of its package. You should ensure that the node images you use are updated to versions that contain the fix for CVE-2022-0847.

High

GCP-2022-011

Published: 2022-03-22
Updated: 2022-08-11

2022-08-11 Update: Added more details about the effects of the SMT misconfiguration.

GKE

Description Severity

Update 2022-08-11: Added more information about the Simultaneous Multi-Threading (SMT) configuration. SMT was intended to be disabled, but was enabled on the versions listed.

If you manually enabled SMT for a sandboxed node pool, SMT will remain manually enabled despite this issue.


There is a misconfiguration with Simultaneous Multi-Threading (SMT), also known as Hyper-threading, on GKE Sandbox images. The misconfiguration leaves nodes potentially exposed to side channel attacks such as Microarchitectural Data Sampling (MDS) (for more context, see GKE Sandbox documentation). We do not recommend using the following affected versions:

  • 1.22.4-gke.1501
  • 1.22.6-gke.300
  • 1.23.2-gke.300
  • 1.23.3-gke.600

If you manually enabled SMT for a node pool, then this issue does not affect your sandboxed nodes.

What should I do?

Upgrade your nodes to one of the following versions:

  • 1.22.6-gke.1500 and later
  • 1.23.3-gke.1100 and later

What vulnerability is addressed by this patch?

GKE Sandbox nodes have SMT disabled by default, mitigating side-channel attacks.

Medium

GCP-2022-009

Published: 2022-03-01
Updated: 2022-03-15

GKE

Description Severity

Update 2022-03-15: Added hardening guides for Anthos clusters on AWS (GKE on AWS) and Anthos on Azure. Added a section on persistence using webhooks.


Some unexpected paths to access the node VM on GKE Autopilot clusters could have been used to escalate privileges in the cluster. These issues have been fixed and no further action is required. The fixes address issues reported through our Vulnerability Reward Program.

GKE Standard and Anthos clusters users can optionally apply a similar hardening policy as described below.

Technical details

Host access using third party policy exemptions

In order to allow Google Cloud to offer full management of nodes, and a Pod-level SLA, GKE Autopilot restricts some highly privileged Kubernetes primitives to limit workloads from having low-level access to the node VM. To set this in context: GKE Standard presents full access to the underlying compute, Autopilot presents limited access, and Cloud Run presents no access.

Autopilot relaxes some of those restrictions for a predefined list of third party tools to allow customers to run those tools on Autopilot without modification. Using privileges to create pods with host path mounts, the researcher was able to run a privileged container in a pod that looked like one of these allowlisted third party tools to gain access to the host.

The ability to schedule pods in this way is expected on GKE Standard, but not on GKE Autopilot, as it bypassed the host-access restrictions used to enable the SLA described previously.

This issue was fixed by tightening the third party allow-listing pod specification.

Privilege escalation from root-on-node

In addition to the host access, the stackdriver-metadata-agent-cluster-level and the metrics-server pods were identified as highly privileged. After gaining root-level access to the node, these services could be used to gain further control over the cluster.

We have deprecated and removed the stackdriver-metadata-agent for both GKE Standard and Autopilot. This component is still in use on Anthos clusters on VMware and Anthos on bare metal.

As a system hardening measure to prevent this type of attack in the future, we'll apply an Autopilot constraint in an upcoming release that prevents updates to the service account of various objects in the kube-system namespace. We developed a Gatekeeper policy for you to apply similar protection to GKE Standard clusters and Anthos clusters to prevent privileged workload self-modification. This policy is applied automatically for Autopilot clusters. For instructions, refer to the following hardening guides:


Addition 2022-03-15: Persistence using mutating webhooks

Mutating webhooks were used in the report to establish a privileged foothold in the cluster post-compromise. These are standard parts of the Kubernetes API created by cluster admins, and were made visible to administrators when Autopilot added support for customer-defined webhooks.


Privileged service accounts in the default namespace

Autopilot policy enforcers previously allowlisted two service accounts in the default namespace: csi-attacher and otelsvc to give the service accounts special privileges. An attacker with high privileges, including permissions to create ClusterRoleBinding objects and with access to create pods in the default namespace, could use these service account names to access those additional privileges. These services were moved under the kube-system namespace to get the protection of existing Autopilot policy. GKE Standard clusters and Anthos clusters are unaffected.

What should I do?

All GKE Autopilot clusters have had their policies updated to remove the unintended host access and no further action is required.

Further policy hardening will be applied to Autopilot in the coming weeks as a secondary protection. No action is required.

GKE Standard clusters and Anthos clusters are unaffected as users already have access to the host. As a system hardening measure, GKE Standard clusters and Anthos clusters users can apply similar protection with a Gatekeeper policy that prevents privileged workload self-modification. For instructions, refer to the following hardening guides:

Low

GCP-2022-008

Published: 2022-02-23
Updated: 2022-04-28
Reference: CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, CVE-2022-21656

GKE

Description Severity
The Envoy project recently discovered a set of vulnerabilities, CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, and CVE-2022-21656 which may impact GKE clusters using Anthos Service Mesh, Istio-on-GKE, or custom Istio deployments.
All issues listed below are fixed in Envoy release 1.21.1.
Technical Background
Additional details for these vulnerabilities are available here.

What should I do?

GKE clusters running Anthos Service Mesh should upgrade to a supported version with fix to the above vulnerabilities
  • If you're using Anthos Service Mesh 1.12, upgrade to v1.12.4-asm.0.
  • If you're using Anthos Service Mesh 1.11, upgrade to v1.11.7-asm.1.
  • If you're using Anthos Service Mesh 1.10, upgrade to v1.10.6-asm.1.
If you're using Anthos Service Mesh v1.9 or below, your release has reached end of life and is no longer supported. These CVE fixes have not been backported. You should upgrade to ASM 1.10 or above.

GKE clusters running Istio-on-GKE should upgrade to a supported version with fix to the above vulnerabilities
  • If you're using Istio-on-GKE 1.6, upgrade to v1.6.14-gke.8.
  • If you're using Istio-on-GKE 1.4.11, upgrade to v1.4.11-gke.4.
  • If you're using Istio-on-GKE 1.4.10, upgrade to v1.4.10-gke.23.
  • If you are using GKE 1.22 or higher, please use Istio GKE 1.4.10. Otherwise, use Istio-on-GKE 1.4.11.

What vulnerabilities are addressed by this patch?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, and CVE-2022-21656
High

Anthos clusters on VMware

Updated: 2022-04-28

Description Severity
Envoy recently released multiple security vulnerability fixes. Anthos clusters on VMware is impacted because Envoy is used with metrics-server. The Envoy CVEs we are fixing are listed below. We will update this bulletin with specific versions when they're available:
  • CVE-2021-43824 (CVSS score 6.5, Medium): Potential null pointer dereference when using JWT filter safe_regex match.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use JWT filter regex.
  • CVE-2021-43825 (CVSS score 6.1, Medium): Use-after-free when response filters increase response data, and increased data exceeds downstream buffer limits.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a decompress filter.
  • CVE-2021-43826 (CVSS score 6.1, Medium): Use-after-free when tunneling TCP over HTTP, if downstream disconnects during upstream connection establishment.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a tunneling filter.
  • CVE-2022-21654 (CVSS score 7.3, High): Incorrect configuration handling allows mTLS session reuse without re-validation after validation settings have changed.
    Note: All ASM/Istio-on-GKE services using mTLS are impacted by this CVE.
  • CVE-2022-21655 (CVSS score 7.5, High): Incorrect handling of internal redirects to routes with a direct response entry.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a direct response filter.
  • CVE-2022-23606 (CVSS score 4.4, Medium): Stack exhaustion when a cluster is deleted via Cluster Discovery Service.
    Note: ASM 1.11+ are impacted by this CVE. ASM 1.10 and All Istio-on-GKE are not impacted by this CVE.
  • CVE-2022-21657 (CVSS Score 3.1, Low): Envoy through 1.20.1 contains a remotely exploitable vulnerability due to X.509 Extended Key Usage and Trust Purposes bypass.
  • CVE-2022-21656 (CVSS Score 3.1, Low): Envoy through 1.20.1 contains a remotely exploitable vulnerability due to X.509 subjectAltName matching (and nameConstraints) bypass.

Istio recently released one security vulnerability fix. Anthos on VMware is impacted because Istio is used for ingress. The Istio CVEs we are fixing are listed below. We will update this bulletin with specific versions when they're available:

CVE-2022-23635 (CVSS score 7.5, High): Istiod crashes upon receiving requests with a specially crafted `authorization` header.


For the full descriptions and impacts of the above CVEs, please refer to the security bulletins.

2022-04-28 Addition: What should I do?

The following versions of Anthos clusters on VMware fix these vulnerabilities:

  • 1.9.5
  • 1.10.3
  • 1.11.0

What vulnerabilities are addressed by this patch?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, and CVE-2022-21656
High

Anthos on bare metal

Description Severity
Envoy recently released multiple security vulnerability fixes. Anthos on Bare metal is impacted because Envoy is used for metrics-server. The Envoy CVEs we are fixing in release 1.10.3, 1.9.6, and 1.8.9 are listed below:
  • CVE-2021-43824 (CVSS score 6.5, Medium): Potential null pointer dereference when using JWT filter safe_regex match.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use JWT filter regex.
  • CVE-2021-43825 (CVSS score 6.1, Medium): Use-after-free when response filters increase response data, and increased data exceeds downstream buffer limits.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a decompress filter.
  • CVE-2021-43826 (CVSS score 6.1, Medium): Use-after-free when tunneling TCP over HTTP, if downstream disconnects during upstream connection establishment.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a tunneling filter.
  • CVE-2022-21654 (CVSS score 7.3, High): Incorrect configuration handling allows mTLS session reuse without re-validation after validation settings have changed.
    Note: All ASM/Istio-on-GKE services using mTLS are impacted by this CVE.
  • CVE-2022-21655 (CVSS score 7.5, High): Incorrect handling of internal redirects to routes with a direct response entry.
    Note: Although ASM/Istio-on-GKE do not support Envoy filters, you could be impacted if you use a direct response filter.
  • CVE-2022-23606 (CVSS score 4.4, Medium): Stack exhaustion when a cluster is deleted via Cluster Discovery Service.
    Note: ASM 1.11+ are impacted by this CVE. ASM 1.10 and All Istio-on-GKE are not impacted by this CVE.
  • CVE-2022-21657 (CVSS Score 3.1, Low): Envoy through 1.20.1 contains a remotely exploitable vulnerability due to X.509 Extended Key Usage and Trust Purposes bypass.
  • CVE-2022-21656 (CVSS Score 3.1, Low): Envoy through 1.20.1 contains a remotely exploitable vulnerability due to X.509 subjectAltName matching (and nameConstraints) bypass.
Istio recently released one security vulnerability fix. Anthos on Bare metal is impacted because Istio is used for ingress. The Istio CVE we are fixing in release 1.10.3, 1.9.6, and 1.8.9 is listed below:

  • CVE-2022-23635 (CVSS score 7.5, High): Istiod crashes upon receiving requests with a specially crafted `authorization` header.
    Note: All ASM/Istio-on-GKE are impacted by this CVE.

For the full descriptions and impacts of the above CVEs, please refer to the security bulletins.

What vulnerabilities are addressed by this patch?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, and CVE-2022-21656
High

GCP-2022-006

Published: 2022-02-14
Updated: 2022-05-16
2022-05-16 Update: Added GKE version 1.19.16-gke.7800 or later to the list of versions that have code to fix this vulnerability.
2022-05-12 Update: Updated patch versions for GKE, Anthos on bare metal, Anthos clusters on VMware, and Anthos clusters on AWS. Fixed an issue where the security bulletin for Anthos clusters on AWS was not displayed when it was added on 2022-02-23.

GKE

Description Severity

A security vulnerability, CVE-2022-0492, has been discovered in the Linux kernel's cgroup_release_agent_write function. The attack uses unprivileged user namespaces and under certain circumstances this vulnerability can be exploitable for container breakout.

What should I do?

2022-05-16 Update: In addition to the GKE versions mentioned in the 2022-05-12 update, GKE version 1.19.16-gke.7800 or later also contains code that fixes this vulnerability.


2022-05-12 Update: The following versions of GKE contain code that fixes this vulnerability:

  • 1.20.15-gke.5600 or later
  • 1.21.11-gke.1500 or later
  • 1.22.8-gke.1800 or later
  • 1.23.5-gke.1800 or later

Update 2022-02-15: Corrected gVisor statement.

The vulnerability is found in the Linux kernel's cgroup_release_agent_write in the kernel/cgroup/cgroup-v1.c function and can be used as a container breakout. GKE is unaffected due to protection from the default AppArmor profile on Ubuntu and COS. However, some customers may still be vulnerable if they have loosened security restrictions on pods through modification of the Pod or container securityContext field e.g. by disabling/changing the AppArmor profile, which is not recommended. In addition to the default AppArmor profile, these features also protect against the vulnerability:

  • GKE Autopilot is unaffected due to the default seccomp profile.
  • Update 2022-02-15: gVisor (GKE Sandbox) is unaffected as gVisor doesn't allow access to the vulnerable system call on the host.

Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerability is addressed by this patch?

CVE-2022-0492

Low

Anthos clusters on

Description Severity

A security vulnerability, CVE-2022-0492, has been discovered in the Linux kernel's cgroup_release_agent_write function. The attack uses unprivileged user namespaces and under certain circumstances this vulnerability can be exploitable for container breakout.

What should I do?

2022-05-12 Update: The following versions of Anthos clusters on VMware contain code that fixes this vulnerability.

COS
  • 1.8.8 or later
  • 1.9.5 or later
  • 1.10.2 or later
  • 1.11.0 or later
Ubuntu
  • 1.9.6 or later
  • 1.10.3 or later
  • 1.11.0 or later

The vulnerability is found in the Linux kernel's cgroup_release_agent_write in the kernel/cgroup/cgroup-v1.c function and can be used as a container breakout. Anthos clusters on VMware are unaffected due to protection from the default AppArmor profile on Ubuntu and COS. However, some customers may still be vulnerable if they have loosened security restrictions on pods through modification of the Pod or container securityContext field e.g. by disabling/changing the AppArmor profile, which is not recommended.

Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerability is addressed by this patch?

CVE-2022-0492

Low

Anthos clusters on AWS

Description Severity

A security vulnerability, CVE-2022-0492, has been discovered in the Linux kernel's cgroup_release_agent_write function. The attack uses unprivileged user namespaces and under certain circumstances this vulnerability can be exploitable for container breakout.

What should I do?

2022-05-12 Update: The following versions of current and previous generation Anthos clusters on AWS contain code that fixes this vulnerability:

Current generation
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300
Previous generation
  • 1.22.8-gke.1300
  • 1.21.11-gke.1100
  • 1.20.15-gke.5200

Update 2022-02-23: Added note for Anthos clusters on AWS.

Anthos clusters on AWS previous and current generations are unaffected due to protection from the default AppArmor profile on Ubuntu. However, some customers may still be vulnerable if they have loosened security restrictions on pods through modification of the Pod or container securityContext field e.g. by disabling/changing the AppArmor profile, which is not recommended.

Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerability is addressed by this patch?

CVE-2022-0492

Low

Anthos on

Description Severity

A security vulnerability, CVE-2022-0492, has been discovered in the Linux kernel's cgroup_release_agent_write function. The attack uses unprivileged user namespaces and under certain circumstances this vulnerability can be exploitable for container breakout.

What should I do?

2022-05-12 Update: The following versions of Anthos on Azure contain code that fixes this vulnerability:

  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Anthos on Azure are unaffected due to protection from the default AppArmor profile on Ubuntu. However, some customers may still be vulnerable if they have loosened security restrictions on pods through modification of the Pod or container securityContext field e.g. by disabling/changing the AppArmor profile, which is not recommended.

Patches will be available in an upcoming release. This bulletin will be updated when they are available.

What vulnerability is addressed by this patch?

CVE-2022-0492

Low

GCP-2022-005

Published: 2022-02-11
Updated: 2022-02-15
Reference: CVE-2021-43527

GKE

Description Severity
Update 2022-02-15: Some GKE versions mentioned in the original bulletin were combined with other fixes and had their version numbers incremented prior to release. Patches are available in the following GKE versions:
  • 1.20.15-gke.300
  • 1.21.9-gke.300
  • 1.22.6-gke.1000

A security vulnerability, CVE-2021-43527, has been discovered in any binary that links to the vulnerable versions of libnss3 found in NSS (Network Security Services) versions prior to 3.73 or 3.68.1. Applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted, depending on how NSS is used/configured. Both GKE COS and Ubuntu images have a vulnerable version installed, and need to be patched.

Potentially, CVE-2021-43527 can have a wide impact across applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS#7, or PKCS#12. As well as applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted. Impact depends on how NSS is used/configured.

GKE doesn't use libnss3 for any Internet-accessible APIs. The impact is limited to on-host code running outside containers, which is small due to the minimal design of Chrome OS. GKE code running inside containers using the golang distroless base image is unaffected.

What should I do?

The versions of Linux node images for the following versions of GKE have been updated with code to fix these vulnerabilities. Upgrade your control plane and nodes to one of the following GKE versions:

  • 1.18 version to be determined
  • 1.19.16-gke.6100
  • 1.20.15-gke.200
  • 1.21.9-gke.200
  • 1.22.6-gke.600
  • 1.23.3-gke.500
Are you using a GKE version older than 1.18? You are using a GKE version out of SLA and should consider upgrading to one of the supported versions.

What vulnerability is addressed by this patch?

CVE-2021-43527

Medium

Anthos clusters on

Description Severity

A security vulnerability, CVE-2021-43527, has been discovered in any binary that links to the vulnerable versions of libnss3 found in NSS (Network Security Services) versions prior to 3.73 or 3.68.1. Applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted, depending on how they configure NSS. Both Anthos clusters on VMware COS and Ubuntu images have a vulnerable version installed, and need to be patched.

Potentially, CVE-2021-43527 can have a wide impact across with applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS \#7, or PKCS \#12. As well as applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted. Impact depends on how they configure/use NSS. Anthos on VMware doesn't use libnss3 for any publicly accessible APIs, therefore the impact is limited and this CVE's severity for Anthos clusters on VMware is rated as Medium.

What should I do?

The versions of Linux node images for the following versions of Anthos have been updated with code to fix these vulnerabilities. Upgrade your control plane and nodes to one of the following Anthos versions:

  • 1.8.7
  • 1.9.4
  • 1.10.2

Are you using an Anthos clusters on VMware version older than 1.18? You are using an Anthos version out of SLA and should consider upgrading to one of the supported versions.

What vulnerability is addressed by this patch?

CVE-2021-43527

Medium

Anthos on

Description Severity

A security vulnerability, CVE-2021-43527, has been discovered in any binary that links to the vulnerable versions of libnss3 found in NSS (Network Security Services) versions prior to 3.73 or 3.68.1. Applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted, depending on how NSS is used/configured. Anthos clusters on Azure Ubuntu images have a vulnerable version installed, and need to be patched.

Potentially, CVE-2021-43527 can have a wide impact across with applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS#7, or PKCS#12. As well as applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted. Impact depends on how they configure/use NSS. Anthos clusters on Azure doesn't use libnss3 for any publicly accessible APIs, therefore the impact is limited and this CVE's severity for Anthos on Azure is rated as Medium.

What should I do?

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

  • v1.21.6-gke.1500

What vulnerability is addressed by this patch?

CVE-2021-43527

Medium

GCP-2022-004

Published: 2022-02-04
Reference: CVE-2021-4034

GKE

Description Severity

A security vulnerability, CVE-2021-4034, has been discovered in pkexec, a part of the Linux policy kit package (polkit), that allows an authenticated user to perform a privilege escalation attack. PolicyKit is generally used only on Linux desktop systems to allow non-root users to perform actions such as rebooting the system, installing packages, restarting services etc, as governed by a policy.

What should I do?

GKE is unaffected because the vulnerable module, policykit-1, is not installed on COS or Ubuntu images used in GKE. No action is required.

None

Anthos clusters on

Description Severity

A security vulnerability, CVE-2021-4034, has been discovered in pkexec, a part of the Linux policy kit package (polkit), that allows an authenticated user to perform a privilege escalation attack. PolicyKit is generally used only on Linux desktop systems to allow non-root users to perform actions such as rebooting the system, installing packages, restarting services etc, as governed by a policy.

The Anthos default configuration already gives users full "sudo" privileges, so this exploit does not change Anthos existing security posture

Technical details

For this bug to be exploitable, an attacker needs both a non-root shell on the node filesystem and to have the vulnerable version of pkexec installed. While Anthos clusters on VMware does include a version of policykit-1 in its release images, the Anthos default configuration allows passwordless sudo to anyone with shell access already, so this vulnerability does not give a user any more privileges than they already have.

What should I do?

No action is required. Anthos clusters on VMware is unaffected.

None

Anthos clusters on

Description Severity
Anthos clusters on AWS is unaffected. The vulnerable module, policykit-1, is not installed on Ubuntu images used by the current and previous versions of Anthos clusters on AWS. None

Anthos on

Description Severity

A security vulnerability, CVE-2021-4034, has been discovered in pkexec, a part of the Linux policy kit package (polkit), that allows an authenticated user to perform a privilege escalation attack. PolicyKit is generally used only on Linux desktop systems to allow non-root users to perform actions such as rebooting the system, installing packages, restarting services etc, as governed by a policy.

The Anthos default configuration already gives users full "sudo" privileges, so this exploit does not change Anthos existing security posture

Technical details

For this bug to be exploitable, an attacker needs both a non-root shell on the node filesystem and to have the vulnerable version of pkexec installed. While Anthos on Azure does include a version of policykit-1 in its release images, the Anthos default configuration allows passwordless sudo to anyone with shell access already, so this vulnerability does not give a user any more privileges than they already have.

What should I do?

No action is required. Anthos on Azure is unaffected.

None

Anthos clusters on

Description Severity
Anthos on bare metal might be affected depending on packages that are installed on the customer-managed operating system. Scan your OS images and patch them if necessary. None

GCP-2022-002

Published: 2022-02-01
Updated: 2022-03-07
Reference:
CVE-2021-4154, CVE-2021-22600, CVE-2022-0185
2022-02-04 Update: Added sections for Anthos clusters on AWS and Anthos on Azure. Added rollout updates for GKE and Anthos clusters on VMware.

GKE

Updated: 2022-03-07

Description Severity

Three security vulnerabilities, CVE-2021-4154, CVE-2021-22600, and CVE-2022-0185, have been discovered in the Linux kernel, each of which can lead to either a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all node operating systems (COS and Ubuntu) on GKE, Anthos clusters on VMware, Anthos clusters on AWS (current and previous generation), and Anthos on Azure.

Pods using GKE Sandbox are not vulnerable to these vulnerabilities.

See the COS release notes for more details.

Technical details

In CVE-2021-4154, an attacker can exploit the fsconfig system call parameter to trigger a use-after-free bug in the linux kernel, resulting in getting root privileges. This is a local privilege escalation attack that will lead to a container breakout.

CVE-2021-22600 is a double free exploit in packet_set_ring that can lead to a container escape to the host node.

With CVE-2022-0185, a heap overflow bug in legacy_parse_param() may lead to an out-of-bounds write that will cause a container breakout.

The exploitation path for this vulnerability that relies on the "unshare" syscall is blocked on GKE Autopilot clusters by default using seccomp filtering.

Users who have manually enabled the default container runtime seccomp profile on GKE Standard clusters are also protected.

What should I do?

2022-03-07 Update:The versions of Linux node images for the following versions of GKE have been updated with code to fix all these vulnerabilities for both Ubuntu and COS images. Upgrade your control plane and nodes to one of the following GKE versions.

  • 1.18.20-gke.6101
  • 1.19.16-gke.8300
  • 1.20.15-gke.2500
  • 1.21.10-gke.400
  • 1.22.7-gke.900
  • 1.23.3-gke.1100

2022-02-25 Update:If you use Ubuntu node images, 1.22.6-gke.1000 does not address CVE-2021-22600. We will update this bulletin with Ubuntu patch versions when they are available.


2022-02-23 Update: The versions of Linux node images for the following versions of GKE have been updated with code to fix these vulnerabilities. Upgrade your clusters to one of the following GKE versions.

  • 1.18.20-gke.6101
  • 1.22.6-gke.1000
  • 1.23.3-gke.1100

2022-02-04 Update: The rollout start date for GKE patch versions was February 2.


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

  • 1.19.16-gke.6100
  • 1.20.15-gke.300
  • 1.21.9-gke.300

1.22 and 1.23 versions are also in progress. We will update this bulletin with specific versions when they're available.

What vulnerability is addressed by this patch?

High

Anthos clusters on

Updated: 2022-02-23

Description Severity

Three security vulnerabilities, CVE-2021-4154, CVE-2021-22600, and CVE-2022-0185, have been discovered in the Linux kernel, each of which can lead to either a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all node operating systems (COS and Ubuntu) on GKE, Anthos clusters on VMware, Anthos clusters on AWS (current and previous generation), and Anthos on Azure.

See the COS release notes for more details.

Technical details

In CVE-2021-4154, an attacker can exploit the fsconfig system call parameter to trigger a use-after-free bug in the linux kernel, resulting in getting root privileges. This is a local privilege escalation attack that will lead to a container breakout.

CVE-2021-22600 is a double free exploit in packet_set_ring that can lead to a container escape to the host node.

With CVE-2022-0185, a heap overflow bug in legacy_parse_param() may lead to an out-of-bounds write that will cause a container breakout.

Users who have manually enabled the default container runtime seccomp profile on GKE Standard clusters are also protected.

What should I do?

2022-02-23 Update: version 1.10.2 (Fixes CVE-2021-22600, CVE-2021-4154, and CVE-2022-0185) is now scheduled for March 1.

2022-02-23 Update: Added patched versions addressing CVE-2021-2260.

Version 1.10.1 does not address CVE-2021-22600 but does address the other vulnerabilities. Versions 1.9.4 and 1.10.2, both unreleased, will address CVE-2021-22600. The versions of Linux node images for the following versions of Anthos clusters on VMware have been updated with code to fix these vulnerabilities. Upgrade your clusters to one of the following Anthos clusters on VMware versions:

  • 1.10.1 (Fixes CVE-2021-4154 and CVE-2022-0185. Released February 10)
  • 1.8.7 (Fixes CVE-2021-22600, CVE-2021-4154, and CVE-2022-0185. Released February 17)
  • 1.9.4 (Fixes CVE-2021-22600, CVE-2021-4154, and CVE-2022-0185. Released February 23)
  • 1.10.2 (Fixes CVE-2021-22600, CVE-2021-4154, and CVE-2022-0185. Scheduled for February 24)

2022-02-04 Update: Added information about Ubuntu images not addressing CVE-2021-22600.

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

  • 1.10.1 (COS update only. Ubuntu patch will be in 1.10.2-scheduled for February 23)
  • 1.9.4 (scheduled for February 15)
  • 1.8.7 (scheduled for February 15)

What vulnerability is addressed by this patch?

High

Anthos clusters on

Description Severity

Three security vulnerabilities, CVE-2021-4154, CVE-2021-22600, and CVE-2022-0185, have been discovered in the Linux kernel, each of which can lead to either a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all node operating systems (COS and Ubuntu) on GKE, Anthos clusters on VMware, Anthos clusters on AWS (current and previous generation), and Anthos on Azure.

See the COS release notes for more details.

Technical details

In CVE-2021-4154, an attacker can exploit the fsconfig system call parameter to trigger a use-after-free bug in the linux kernel, resulting in getting root privileges. This is a local privilege escalation attack that will lead to a container breakout.

CVE-2021-22600 is a double free exploit in packet_set_ring that can lead to a container escape to the host node.

With CVE-2022-0185, a heap overflow bug in legacy_parse_param() may lead to an out-of-bounds write that will cause a container breakout.

Users who have manually enabled the default container runtime seccomp profile on GKE Standard clusters are also protected.

What should I do?

Anthos clusters on AWS

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

  • 1.21.6-gke.1500 and later (available in February)

Anthos clusters on AWS (previous generation)

The versions of Linux node images for the following versions of Anthos clusters on AWS (previous generation) have been updated with code to fix these vulnerabilities. Upgrade your clusters to one of the following Anthos clusters on AWS (previous generation) versions:

  • 1.19.16-gke.5300
  • 1.20.14-gke.2000
  • 1.21.8-gke.2000

What vulnerability is addressed by this patch?

High

Anthos on

Description Severity

Three security vulnerabilities, CVE-2021-4154, CVE-2021-22600, and CVE-2022-0185, have been discovered in the Linux kernel, each of which can lead to either a container breakout, privilege escalation on the host, or both. These vulnerabilities affect all node operating systems (COS and Ubuntu) on GKE, Anthos clusters on VMware, Anthos clusters on AWS (current and previous generation), and Anthos on Azure.

See the COS release notes for more details.

Technical details

In CVE-2021-4154, an attacker can exploit the fsconfig system call parameter to trigger a use-after-free bug in the linux kernel, resulting in getting root privileges. This is a local privilege escalation attack that will lead to a container breakout.

CVE-2021-22600 is a double free exploit in packet_set_ring that can lead to a container escape to the host node.

With CVE-2022-0185, a heap overflow bug in legacy_parse_param() may lead to an out-of-bounds write that will cause a container breakout.

Users who have manually enabled the default container runtime seccomp profile on GKE Standard clusters are also protected.

What should I do?

The versions of Linux node images for the following versions of Anthos on Azure have been updated with code to fix these vulnerabilities. Upgrade your clusters to the following Anthos on Azure version:

  • 1.21.6-gke.1500 and later (available in February)

What vulnerability is addressed by this patch?

High

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
Updated: 2021-12-22
Reference: CVE-2020-8554

2021-12-22 update: Uses gcloud beta instead of the gcloud command.

2021-12-15 update: Added additional mitigate for GKE.

GKE

Description Severity
Updated: 2021-12-22 The command for GKE in the following section should use gcloud beta instead of the gcloud command.
gcloud beta container clusters update –no-enable-service-externalips

Updated: 2021-12-15 For GKE, the following mitigation is now available:
  1. Starting in GKE version 1.21, services with ExternalIPs are blocked by a DenyServiceExternalIPs admission controller that is enabled by default for new clusters.
  2. Customers who upgrade to GKE version 1.21 can block services with ExternalIPs using the following command:
    gcloud container clusters update –no-enable-service-externalips
    

For more information, see Hardening your cluster's security.


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
Updated: 2021-12-22 The command for GKE in the following section should use gcloud beta instead of the gcloud command.
gcloud beta container clusters update –no-enable-service-externalips

Updated: 2021-12-15 For GKE, the following mitigation is now available:
  1. Starting in GKE version 1.21, services with ExternalIPs are blocked by a DenyServiceExternalIPs admission controller that is enabled by default for new clusters.
  2. Customers who upgrade to GKE version 1.21 can block services with ExternalIPs using the following command:
    gcloud container clusters update –no-enable-service-externalips
    

For more information, see Hardening your cluster's security.


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
Updated: 2021-12-22 The command for GKE in the following section should use gcloud beta instead of the gcloud command.
gcloud beta container clusters update –no-enable-service-externalips

Updated: 2021-12-15 For GKE, the following mitigation is now available:
  1. Starting in GKE version 1.21, services with ExternalIPs are blocked by a DenyServiceExternalIPs admission controller that is enabled by default for new clusters.
  2. Customers who upgrade to GKE version 1.21 can block services with ExternalIPs using the following command:
    gcloud container clusters update –no-enable-service-externalips
    

For more information, see Hardening your cluster's security.


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.