As part of our continuous efforts to ensure that you are ready for Day 2 and everything it can bring, D2iQ has been granted early knowledge of security threats under embargo. This way, we and other members of the Kubernetes community can develop countermeasures and fixes to address vulnerabilities before they are widely publicized. We issue one of these alerts, describing the threat and what we have done to counter it, upon the lifting of the embargo, so you have the latest information as soon as it is made public.
Jun 01, 2020
Chris Gaun
D2iQ
3 min read
Background and Trigger
A security vulnerability (CVE-2020-8555) with a Medium severity has been reported that affects following versions of Kubernetes:
- kube-controller-manager v1.18.0
- kube-controller-manager v1.17.0 - v1.17.4
- kube-controller-manager v1.16.0 - v1.16.8
- kube-controller-manager < v1.15.11
Note, an attack using this vulnerability requires permission to create a pod or StorageClass and would typically only be granted to internal administrators or developers within an organization. It is possible to mitigate an attack by implementing policies using Gatekeeper and restricting StorageClass using Kubernetes access controls.
D2iQ’s fix for CVE-2020-8555 is found in the following product versions:
- Konvoy 1.17.6+d2iq.1 (for users of current Konvoy Beta / RCs)
- Konvoy1.16.9+d2iq.1
- MKE 2.5.0-1.16.9
MKE with Kubernetes 1.17 is expected in June and will be secured against CVE-2020-8555.
Context and Symptoms
The CVE details were received by D2iQ under embargo until June 1st and were as follows:
“There exists a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master's host network (such as link-local or loopback services).
This issue has been rated medium (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N), and assigned CVE-2020-8555.”
Mitigation and Workarounds
D2iQ customers should upgrade their clusters to one of the secure versions listed above or restrict volume usage using Gatekeeper and StorageClass using Kubernetes access controls.
Kommander, Dispatch, KUDO operator, and Conductor customers running on a version of Kubernetes that is affected should upgrade the underlying clusters.
For Ksphere Konvoy Users
Before you begin
Before installing, ensure that your environment has the following basic requirements:
- Docker Desktop version 18.09.2 or later
You must have Docker Desktop installed on the host where the Konvoy command line interface (CLI) will run. For example, if you are installing Konvoy on your laptop, be sure the laptop has a supported version of Docker Desktop. - kubectl v1.16.9 or later
To enable interaction with the running cluster, you must have kubectl installed on the host where the Konvoy command line interface (CLI) will run. - The konvoy_air_gapped.tar.bz2 that contains the required artifacts to perform an air-gapped installation.
Upgrading
You will follow the instructions in the Konvoy documentation. For Konvoy 1.4.x follow the instructions here. For Konvoy 1.5 Beta users follow the instructions here.
NOTE: your Konvoy cluster.yaml, add the new version of Kubernetes with the suffix as shown below
kind: ClusterConfigurationapiVersion: konvoy.mesosphere.io/v1beta1spec: kubernetes: version: 1.16.9+d2iq.1 imageRepository: docker.io/mesosphere
For Mesosphere MKE Users
MKE users should upgrade their clusters to one of the secure versions listed above. Please follow the upgrade instructions listed here.
Thank you for your prompt attention to this important matter. Together we can ensure that Kubernetes provides enterprise-grade levels of security, reliability, and capability.
