Security Bulletins

From time to time, we might release security bulletins related to Kubernetes Engine. All security bulletins for Kubernetes Engine are described here.

Subscribe to the Kubernetes Engine security bulletins. Subscribe

May 30, 2018

Description Severity Notes

A vulnerability was recently discovered in Git which may allow escalation of privileges in Kubernetes if unprivileged users are allowed to create Pods with gitRepo volumes. The CVE is identified with the tag CVE-2018-11235.

Am I affected?

This vulnerability affects you if all of the following are true:

  • Untrusted users can create Pods (or trigger Pod creation).
  • Pods created by untrusted users have restrictions preventing host root access (for example, via PodSecurityPolicy).
  • Pods created by untrusted users are allowed to use the gitRepo volume type.

All Kubernetes Engine nodes are vulnerable.

What should I do?

Forbid the use of the gitRepo volume type. To forbid gitRepo volumes with PodSecurityPolicy, omit gitRepo from the volumes whitelist in your PodSecurityPolicy.

Equivalent gitRepo volume behavior can be achieved by cloning a git repository into an EmptyDir volume from an initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

What patch addresses this vulnerability?

A patch will be included in an upcoming Kubernetes Engine release. Please check back here for details.

Medium

May 21, 2018

Description Severity Notes

Several vulnerabilities were recently discovered in the Linux kernel which may allow escalation of privileges or denial of service (via kernel crash) from an unprivileged process. These CVEs are identified with tags CVE-2018-1000199, CVE-2018-8897, and CVE-2018-1087. All Kubernetes Engine nodes are affected by these vulnerabilities, and we recommend that you upgrade to the latest patch version, as detailed below.

What should I do?

In order to upgrade, you must first upgrade your master to the newest version. This patch is available in Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1, and Kubernetes Engine 1.10.2-gke.1. These releases include patches for both Container-Optimized OS and Ubuntu images.

If you create a new cluster before then, you must specify the patched version for it to be used. Customers who have node auto-upgrades enabled and who do not manually upgrade will have their nodes upgraded to patched versions in the coming weeks.

What vulnerabilities are addressed by this patch?

The patch mitigates the following vulnerabilities:

CVE-2018-1000199: This vulnerability affects the Linux kernel. It allows an unprivileged user or process to crash the system kernel, leading to a DoS attack or privilege escalation. This is rated as a High vulnerability, with a CVSS of 7.8.

CVE-2018-8897: This vulnerability affects the Linux kernel. It allows an unprivileged user or process to crash the system kernel, leading to a DoS attack. This is rated as a Medium vulnerability, with a CVSS of 6.5.

CVE-2018-1087: This vulnerability affects Linux kernel’s KVM hypervisor. This allows an unprivileged process to crash the guest kernel or potentially gain privileges. This vulnerability is patched in the infrastructure that Kubernetes Engine runs on, so Kubernetes Engine is unaffected. This is rated as a High vulnerability, with a CVSS score of 8.0.

High

March 12, 2018

Description Severity Notes

The Kubernetes project recently disclosed new security vulnerabilities, CVE-2017-1002101 and CVE-2017-1002102, allowing containers to access files outside the container. All Kubernetes Engine nodes are affected by these vulnerabilities, and we recommend that you upgrade to the latest patch version as soon as possible, as we detail below.

What should I do?

Due to the severity of these vulnerabilities, whether you have node auto-upgrades enabled or not, we recommend that you manually upgrade your nodes as soon as the patch becomes available. The patch will be available for all customers by March 16th, but it may be available for you sooner based on the zone your cluster is in, according to the release schedule.

In order to upgrade, you must first upgrade your master to the newest version. This patch will be available in Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1, and Kubernetes 1.7.14-gke.1. New clusters will use the patched version by default by March 30; if you create a new cluster before then, you must specify the patched version for it to be used.

Kubernetes Engine customers who have node auto-upgrades enabled and who do not manually upgrade will have their nodes upgraded to patched versions by April 23rd. However, due to the nature of the vulnerability, we recommend you manually upgrade your nodes as soon as the patch is available to you.

What vulnerabilities are addressed by this patch?

The patch mitigates the following two vulnerabilities:

The vulnerability CVE-2017-1002101 allows containers using subpath volume mounts to access files outside of the volume. This means that if you are blocking container access to hostpath volumes with PodSecurityPolicy, an attacker with the ability to update or create pods can mount any hostpath using any other volume type.

The vulnerability CVE-2017-1002102 allows containers using certain volume types - including secrets, config maps, projected volumes, or downward API volumes - to delete files outside of the volume. This means that if a container using one of these volume types is compromised, or if you allow untrusted users to create pods, an attacker could use that container to delete arbitrary files on the host.

To learn more about the fix, read the Kubernetes blog post.

High
Was this page helpful? Let us know how we did:

Send feedback about...

Kubernetes Engine