Kubernetes Vulnerabilities in 2020 and How to Fix Them
Dealing with Kubernetes vulnerabilities shouldn’t be hard
Vulnerabilities in open source are vital to a lot of organizations and developers are paying close attention to. Any little breach can be very bad, especially when it comes to container orchestration.
Kubernetes has become one of the leaders in the container market. Most companies are now employing the capabilities of Kubernetes to manage their container workloads.
According to a survey, over 86% of companies are using Kubernetes for their container operations. Also, self-managed Kubernetes (35%) is now second to Amazon EKS (37%) with just a 2% difference after previously being the most used. Take a look at the figures below:
With all these, you should have guessed by now that there will be a lot of accompanying security vulnerabilities. For every version released, there’s a list of security vulnerabilities discovered and fixes released.
In this article, we’ll be exploring the Kubernetes security vulnerabilities that have been found this year so far, and the security best practices to follow so you can avoid and fix them.
Kubernetes ContainerNetworking — CVE-2020–10749
This was found in all versions of container networking/plugins before the version 0.8.6. It allowed containers in Kubernetes clusters to perform man-in-the-middle (MitM) attacks.
A malicious container can send rogue IPv6 router advertisements to the host or other containers, to redirect traffic to the malicious container, as per the official description. The Bugzilla report it says:
- The vulnerable code is not exploitable in the OpenShift Container Platform 3.11 and considered low.
- OpenShift Container Platform 4 does not forward IPv6 traffic, hence making this vulnerability not exploitable.
The recommended solution is to prevent untrusted, non-privileged containers from running with CAP_NET_RAW. A fix can be found in this upstream.
Jenkins Google Kubernetes Engine — CVE-2020–2121
Jenkins Google Kubernetes Engine Plugin 0.8.0 and earlier does not configure its YAML parser to prevent the instantiation of arbitrary types. This results in a remote code execution vulnerability by users able to provide YAML input files to Google Kubernetes Engine Plugin’s build step, as shown on their website.
As you can see in WhiteSource’s Vulnerability Lab, the severity score for this vulnerability is 8.8 — pretty high. A fix has been released in Google Kubernetes Engine Plugin 0.8.1. It configures its YAML parser to only instantiate safe types.
You will need to have the 0.8.1 version upward to fix this vulnerability.
Kubernetes API Server — CVE-2020–8552
The Kubernetes API server component in versions prior to 1.15.9, 1.16.0–1.16.6, and 1.17.0–1.17.2 has been known to be vulnerable to a denial of service attack through successful API requests.
This vulnerability has effects over the API server which is the cluster’s gateway component responsible for receiving, authenticating, authorizing, and processing administration requests on the cluster. The vulnerability has a severity score of 7.5, which is considered a medium-level vulnerability.
The vulnerability could lead to Denial of Service (DoS) by consuming the memory of the API server. Before Kubernetes v1.14, an attacker could initiate an authorized request to your API cluster through unauthenticated requests, exploiting its vulnerability.
An issue was opened on Kubernetes repo and a fix has been pushed here. To fix this, you will need to upgrade to version v1.18.0-alpha.3 as the vulnerability has been patched in v1.17.3, v1.16.7, and v1.15.10.
Elastic Cloud Kubernetes — CVE-2020–7010
Elastic Cloud on Kubernetes (ECK) versions prior to 1.1.0 generate passwords using a weak random number generator. If an attacker is able to determine when the current Elastic Stack cluster was deployed they may be able to force the Elasticsearch credentials generated by ECK, according to CVE.
There’s really no workaround to fix this other than upgrading to the latest version since the vulnerability fix has been patched already. You will need to upgrade to version 1.1.0 if you are using Elastic Cloud on Kubernetes. You can read upgrade instructions here.
Kubelet API — CVE-2020–8551
The Kubelet component in versions 1.15.0–1.15.9, 1.16.0–1.16.6, and 1.17.0–1.17.2 has been known to be vulnerable to a DoS attack through the Kubelet API. As explained in the official description, this includes the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.
This medium-rated vulnerability affects the Kubelet — the Kubernetes components controlling resources on a node. Like CVE-2020–8552, it can cause a denial of service by consuming the memory of a Kubelet and killing it.
You can read more on the issue here and a fix has been pushed here. This vulnerability is similar to CVE-2020–8552. The fix patched has been applied to version v1.18.0-alpha.4.
Apart from being on the latest version, you should follow the best practices in securing and preventing malicious access to the Kubernetes API server below:
- Always make sure that anonymous authentication is disabled unless you know what you are doing.
- Always make sure that the API server is accessible only from trusted subnets (e.g., via appropriate firewall rules). And also do not expose it on the public Internet at all.
Conclusion
We have explored some vulnerabilities found in Kubernetes so far this year 2020 and know how to fix each of these vulnerabilities.
The best way to beat these vulnerabilities is to:
- Be on the latest version of Kubernetes since all vulnerability mentioned here has been fixed.
- Scan your codebases for vulnerabilities.
- Ensure you are following security best practices.
Security vulnerabilities are a significant issue as more organizations come to rely on Kubernetes for their cloud containers. The effects of these vulnerabilities vary between each cluster depending on their nature and what resources are used to power them. It’s better to be on the safe side and always follow best practices.
