A new version of Anthos clusters on AWS (GKE on AWS) was released on April 30. See the release notes for more information.

Security bulletins

Learn about security bulletins for Anthos clusters on AWS (GKE on AWS).

Use this XML feed to subscribe to Anthos clusters on AWS security bulletins. Subscribe

GCP-2021-003

Published: 2021-04-19
Description Severity Notes

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

CVE-2021-25735

GCP-2021-001

Published: 2021-01-28
Description Severity Notes

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.

This vulnerability could be used in customer-owned application containers to escalate privileges to root inside the container. If your application container is designed to run as non-root, consider updating your container base image to a version containing the fix.

What should I do?

Because Anthos clusters on AWS 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 CVE-2021-3156

GCP-2020-015

Published: 2020-12-07
Description Severity Notes

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

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

All Anthos clusters on 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

CVE-2020-8554

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

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 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 Anthos clusters on AWS versions or newer 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

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?

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

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?

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

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