“There are always going to be vulnerabilities,” explained Rani Osnat, vice president of product marketing at Aqua Security. “The fact that one was found was to be expected. And I expect more will be found going forward. That’s just what should be expected with software.”
The flaw itself was discovered earlier this month by a software engineer at Rancher Labs. It impacted all Kubernetes-based products and services, and gave hackers full administrative privileges on any compute node being run in a Kubernetes cluster. The flaw garnered a 9.8 (critical) score out of 10 on the Common Vulnerability Scoring System (CVSS).
A patch was produced within 24 hours of the flaw being discovered and disseminated to the Kubernetes community. That patch worked to protect Kubernetes versions back to the 1.10 release from earlier this year.
The timing of the flaw being found was fortuitous as it came just a week ahead of the KubeCon + CloudNativeCon North America 2018 event in Seattle. The topic was tackled head on by a number of speakers and vendors at the event.
“We should not be surprised or afraid that issues have been found,” explained Liz Rice, a technology evangelist at Aqua Security, during a keynote address at the event. “All systems have these.”
The timing also came on the same day that the Kubernetes project released the 1.13 version of the platform. Aaron Crickenberger, who works for Google and was a member of the 1.13 release team, explained that the timing was purely coincidental.
That latest Kubernetes release was the fastest produced by the project taking just 10 weeks instead of the usual 12 weeks. However, Josh Berkus, who works for Red Hat and was also on the Kubernetes 1.13 release team, said that security issues like the one that popped up don’t have any impact on the Kubernetes release cycle.
Osnat said that he did not think the latest vulnerability will impact uptake of Kubernetes.
“I think that since this was exposed and communicated about so quickly provides enterprises with a level of comfort and it also helps to drive the security discussion further,” Osnat said, adding that the rapid pace in which the vulnerability was fixed “showed maturity in the ecosystem and that the community is taking security seriously.”
Dan Berg, a distinguished engineer for IBM’s Cloud Kubernetes Services, said that it was able to update its hosted customers within 24 hours. “And there was nothing that our customers had to do,” Berg noted.
“Overall we were pretty happy with how the ecosystem reacted to the security issue,” Berg said. “That helped us and allowed us to see how it would impact our customers.”
The latest flaw was not the first issue to plague the Kubernetes community.
Cloud security provider Lacework earlier this year found more than 21,000 open container orchestration and API management systems on the internet that were vulnerable as attack points for possible hacking. Those open systems included deployments using Kubernetes, Docker Inc.’s Swarm, Mesos Marathon, Red Hat OpenShift, Portain.io, and Swarmpit.
Specific to Kubernetes, Lacework found open dashboards that were in the midst of being set up and thus not fully protected; open dashboards with no authentication; open dashboards that could be “brute force” attacked using a certain level of skill; and information disclosures of the organizations that had deployed Kubernetes, thus giving an attacker a target to aim for.
The Kubernetes security issue was part of a cryptojacking attack earlier this year on Tesla. RedLock Cloud Security Intelligence found hackers had compromised Tesla’s Kubernetes console, which had not been password protected. One of those Kubernetes pods contained sensitive data, including telemetry information.
Kromtech Security found a similar opening on a Kubernetes deployment by Weight Watchers.
“These all just show that the community is able to act quickly when a flaw is found but more importantly that enterprises need to be aware when deploying Kubernetes,” Osnat added. “There are security solutions out there and one of those is just being aware.”