A new version of GKE on AWS was released on November 2. See the release notes for more information.

Security bulletins

Learn about security bulletins for GKE on AWS.

GCP-2020-014

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

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

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

GKE on 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
Updated: 2020-10-13
Description Severity Notes

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

All GKE 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 GKE 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

CVE-2020-14386

GCP-2020-011

Published: 2020-07-24
Description Severity Notes

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

Exploiting this vulnerability on GKE on AWS 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 GKE on AWS.

What should I do?

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

  • GKE on AWS 1.4.1-gke.17

What vulnerability is addressed by this patch?

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

Low

CVE-2020-8558

GCP-2020-009

Published: 2020-07-15
Description Severity Notes

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

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

What should I do?

GKE 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

CVE-2020-8559

GCP-2020-007

Published: 2020-06-01
Description Severity Notes

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

What should I do?

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

CVE-2020-8555

GCP-2020-006

Published: 2020-06-01
Description Severity Notes

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

What should I do?

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

Kubernetes issue 91507