A recently identified security flaw in Kubernetes container orchestration software is adding fuel to a simmering debate over how the Kubernetes update process should be managed.
The security flaw involves a privilege escalation issue that was found that affects all versions of the Kubernetes API server. A cybercriminal could use this flaw to access every single machine in a cluster via the API server. The team that oversees the development of Kubernetes is recommending that every organization running Kubernetes immediately update their Kubernetes clusters to remediate the issue. The trouble is, the latest release of Kubernetes is not backward-compatible with every previous release. In addition to having to provision new clusters, many IT organizations could find their existing Kubernetes applications no longer work.
To avoid that issue, providers of curated instances of Kubernetes have started offering patch updates to older versions of Kubernetes. Those patches replace a grand total of 37 lines of code. In an ideal world, most organizations would stay current on Kubernetes releases. Practically speaking, however, that’s not feasible for IT organizations that now find themselves running multiple versions of Kubernetes clusters that are not backward compatible with one another.
Banjot Chanana, vice president of product for Docker Inc., says the issue this and other potential security flaw raises is the need for a Long-Term Release (LTR) of Kubernetes that IT organizations can rely. Kubernetes is updated on a quarterly cadence. But many IT organizations find it challenging to absorb that rate of change. Updates to Kubernetes that require IT organizations to update applications are viewed as being even more problematic.
Most of the organizations contributing to Kubernetes have made extensive investments in adopting best DevOps processes that make it easier for them to absorb API changes. Traditional enterprise IT organizations, however, often don’t have access to the same level of DevOps expertise.
Unfortunately, there’s no way to know just how serious the security flaw discovered in Kubernetes is because there’s no way of knowing whether hackers employed it to compromise a Kubernetes cluster. But the existence of the flaw coupled with the potential impact to containerized applications running on older instances of Kubernetes is a cause for concern for traditional enterprise IT organizations that tend to rely more on IT administrators than software engineers to keep their IT environment running. The degree to which an LTR edition of Kubernetes solves that problem may be debatable. But like it or not, the first rule of IT operations inside many organizations is to do no application harm.
Wei Lien Dang, vice president of products for StackRox, a provider of container security software, says it’s not likely flaws of this magnitude will be discovered frequently, so a LTS version of Kubernetes shouldn’t be necessary to address this type of issue specifically. An LTS version also has the potential to introduce more security issues since the overall codebase will be older, Lien Dang notes, adding the best solution for this type of scenario will require the community to focus on making upgrades easier.
In the meantime, IT organizations that have already deployed Kubernetes will continue to cross their fingers in the hope this security flaw is more of an aberration than a sign of more to come.