The tech industry press has been abuzz this week with news of the first major security hole discovered in Kubernetes, with coverage in ZDNet, The Stack, and TechTarget’s Search IT Operations. Given the prevalence of Kubernetes in organizations’ tech stacks and the fact that it’s the first discovered security flaw, the news is pretty big.
Here at StackRox, we were surprised in a couple ways — first, with its scope, and second, that it wasn’t discovered earlier. The vulnerability — CVE-2018-1002105 — enables attackers to compromise clusters via the Kubernetes API server. This vulnerability has existed in every version of Kubernetes since v1.0 — that means everyone using Kubernetes is potentially affected. But we’re also keenly aware that Kubernetes is complex software — we’ve taken great pains, for example, in the StackRox Kubernetes Security Platform to make the functionality of Kubernetes more accessible to organizations.
Along with its complexity, Kubernetes has a large codebase — together, these dynamics can be expected to lead to security issues. The simplicity of the fix — a mere 37 lines of code — speaks to the maturity and high quality of the Kubernetes codebase. Our greatest concern is that it is difficult to detect when this vulnerability is being exploited — along with the fact we’ve previously noted that everyone using Kubernetes could be affected.
Security Challenges for Kubernetes
To date, a lot of the security issues surrounding Kubernetes have focused on misconfigurations. The well-known examples of Tesla getting hacked via an exposed dashboard and Shopify publishing the vulnerability tied to exposed metadata are both rooted in misconfigurations of Kubernetes. This vulnerability is really the first major security hole for Kubernetes.
This vulnerability is tied to the Kubernetes API server, which is central to orchestrating and managing containerized applications. This vulnerability allows a bad actor to access every single machine in a cluster via the API server to compromise the entire environment. All the while, the attacker would appear to be making authorized requests, making it difficult to identify the attack.
Remediating this Kubernetes Security Flaw
Luckily, fixing the flaw is fairly straightforward — an organization must immediately upgrade the version of Kubernetes to one of several recent releases that have been patched. Companies using managed Kubernetes via providers like AWS, Google, and Azure will be less susceptible. For example, Google Kubernetes Engine (GKE) and Amazon Elastic Container Service for Kubernetes (EKS) have already patched the vulnerability for their customers. Red Hat has also issued patched versions for its OpenShift platform.
For customers managing Kubernetes themselves, how quickly they will upgrade to address this issue will depend on their specific processes and practices. Companies who are already limiting network access to the Kubernetes API server as a best practice will have less exposure. But given the broad impact and high-profile nature of this vulnerability, we expect organizations to take fast action.
The Opportunity to Build Trust in Kubernetes
Often security flaws result in people distrusting the software or platform susceptible to the flaw. We don’t expect this outcome for Kubernetes. Instead, we anticipate this disclosure and its subsequent response will generate greater trust and credibility in the platform given the way it was handled. The large community, including committed providers like Red Hat and Google, has demonstrated that it can responsibly identify, fix, and patch a serious security issue quickly. The issue does reinforce, however, the central role that Kubernetes plays today — it has emerged as the OS of the cloud. And companies need to ensure they’re taking all necessary steps to protect such a critical part of their compute infrastructure.
Additional resource: Docker Container Security 101: Risks and 33 Best Practices