As 2018 was coming to a close, and the blistering pace of Kubernetes adoption showed no signs of slowing, the first major Kubernetes security vulnerability was discovered in the container orchestrator (CVE-2018-1002105), with a criticality score of 9.8. The vulnerability enabled attackers to compromise clusters via the Kubernetes API server. Increasing the impact, this vulnerability had existed in every version of Kubernetes since v1.0 — so everyone using Kubernetes at that point was potentially affected. What made it particularly sinister was that exploiting this vulnerability left zero trace — remediation depended on updating to the latest version of Kubernetes, a likely painful project for many.
Over the course of the next twelve months, several new Kubernetes vulnerabilities emerged, each carrying a unique security risk and remediation path. What follows are five of the most risky security vulnerabilities we at StackRox contend you should know about and protect yourself against as you continue your Kubernetes journey into 2020.
Right out of the gates in 2019, a vulnerability in runC, which allowed an attacker to gain host-level code execution by breaking out of a running container, was discovered. This vulnerability was highly significant in that it:
- facilitated container isolation breakout with minimal interaction from an authorized host user;
- typically allowed an attacker to obtain root privileges on the host;
- negatively impacted most container environments because many containers run with default Docker security settings and default user (UID 0); and
- affected runC, the most commonly used low-level container runtime in Docker and Kubernetes environments.
The remediation required you to upgrade to the latest version of runC on all container hosts.
The runC vulnerability was soon followed by a new security issue affecting nearly every version of Kubernetes. CVE-2019-1002100 was a denial of service (DoS) vulnerability that existed in the Kubernetes API server, allowing users with certain write permissions on the Kubernetes API to make write requests, causing the API server to utilize excessive resources.
Although the circumstances under which this vulnerability could be exploited are limited, it still received a medium severity score because all major versions of Kubernetes (v1.0-1.13) were impacted, making the scope of this vulnerability significant.
Remediation required Kubernetes administrators to immediately configure Kubernetes role-based access controls (RBAC) such that only trusted users are permitted to make patch requests.
Discovered in March of 2019, this vulnerability affected the
kubectl binary — specifically, in the
kubectl cp command. The
kubectl cp command is a tool that allows users to copy files and directories between containers running in Kubernetes pods and the user’s machine.
Kubectl cp depends on the
tar binary in a container — when copying files from a container, it creates a tarball inside the container, before copying it over to the user’s machine and untar-ing it.
However, if the container contains a malicious
tar binary, it could construct a malicious tarball that, when extracted on a user’s machine, could replace or delete arbitrary files on it.
As a high severity security issue, this vulnerability carried a simple remediation solution — upgrade to
kubectl client versions 1.11.9, 1.12.7, 1.13.5 or 1.14.0.
A new Kubernetes security vulnerability was discovered in August of 2019, along with patch releases addressing the issue in Kubernetes 1.13, 1.14, and 1.15. This vulnerability impacts the Kubernetes API, allowing users to read, modify, or delete cluster-wide custom resources even if they have RBAC permissions that extend only to namespace resources.
Although CVE-2019-11247 was given a medium severity rating, it still posed an especially serious threat when custom resources were used to manage functionality related to cluster or application security. If your clusters didn’t use Custom Resource Definitions (CRDs), you were spared. But CRDs have become a critical component of many Kubernetes-native projects such as Istio, so many users were impacted.
The simplest way to protect yourself against this vulnerability is to ensure you’re using a patched version of Kubernetes (1.13 or beyond).
One of the most recent security threats to Kubernetes was the “billion laughs” attack vulnerability that allows an attacker to perform a Denial-of-Service (DoS) attack on the Kubernetes API server by uploading a maliciously crafted YAML file.
Once again, being on the latest Kubernetes version removes the threat. Security patches are confined to the last three Kubernetes releases, making it all the more critical that you update frequently.
Aside from always running the most recent version of Kubernetes, you should always follow these best practices in locking down access to the Kubernetes API server:
- Ensure the API server is accessible only from trusted subnets (e.g., via appropriate firewall rules). Even better, do not expose it on the public Internet at all — just in a VPC network.
- Ensure that anonymous authentication is disabled.
As you start the new year, make sure you’re on the latest version of Kubernetes, and ensure you’re following security best practices for your entire cloud-native environment, including: