Kubernetes Vulnerability Hits Top of Severity Scale
The security issue strikes at some of the basic reasons for the rising popularity of containers as an architecture and Kubernetes as an orchestration mechanism.
The first major security vulnerability – 9.8 out of a possible 10 – in Kubernetes was disclosed earlier this week.
The vulnerability (CVE-2018-1002105) allows for privilege escalation and can be accessed by both authorized and unauthorized users. For authorized users with “attach,” “exec,” or “portforward” privileges, escalating those to admin privileges that allow any process to be executed is trivial.
And for anyone at all, an API used in three specific modules will allow a query that returns values that can be used to raise privileges to admin level for any API deployed on the container cluster.
“Depending on the organization’s architecture, this vulnerability is like leaving the door open to the enterprise’s entire cloud environment,” said Nick Morris, managing principal of cyber engineering at Coalfire. “The security risks are made even more challenging in that a compromise might not be detectable as it obfuscates the detection capabilities.”
One of the factors that makes this vulnerability so severe is its scope. “This vulnerability has existed in every version of Kubernetes since v1.0,” said Wei Lien Dang, vice president of products at StackRox. “But Kubernetes is complex software with a large codebase, which can lead, to some extent, to various security issues.”
The security issue strikes at some of the basic reasons for the rising popularity of containers as an architecture and Kubernetes as an orchestration mechanism. “What makes Kubernetes great is its fundamental speed, orchestration, automation, and scale. All of those qualities become an instant detriment when a security issue arises as they rapidly extend the reach of the attack,” said Sumo Logic CSO George Gerchow.
Fortunately for Kubernetes users, two fixes are available for the vulnerability. The first is to update any deployed Kubernetes instances to versions 1.10.11, 1.11.5, 1.12.3 and 1.13.0-rc1. Each has been patched to remediate the vulnerability. Major cloud service providers also have announced that they have patched their instances, and the question is appropriate for any Kubernetes provider.
The Kubernetes vulnerability may provide yet another opportunity for organizations to examine their patching and updating policies. “Companies routinely fail to install updates to known vulnerabilities,” Dang said. “So how many are likely to drag their heels and be exploited by this as a result of inaction? It depends on how they’re deploying and using Kubernetes.”
For companies that are unable to update to one of the patched versions of Kubernetes, mitigation steps have been published that will remove the vulnerability, though developers warn they may also disrupt existing operations for some users. According to Gerchow, protection from this, and similar, vulnerabilities means closer relations between development and security teams, with DevSecOps a legitimate way to improve communication and cooperation. “Most organizations lack visibility into the proper security and configuration of not just its containers but the CI/CD pipeline as a whole,” he says.
Related Content:
Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio
More Insights
Read More HERE