The first major release of 2018 for the open-source Kubernetes container orchestration platform is now available, including a patch for a critical vulnerability that could have enabled an attacker to access the host filesystem.
The open-source Kubernetes container orchestration platform reached its 1.10 release on March 26, providing organizations with new storage and security capabilities.
Among the new features in Kubernetes 1.10 is the beta integration of a new storage capability known as the Container Storage Interface (CSI). The new Kubernetes milestone also provides Transport Layer Security (TLS) bootstrapping capabilities as well patches for a critical security vulnerability.
“Kubernetes features are generally introduced as alpha, moved to beta and eventually to stable/GA, over subsequent Kubernetes releases,” Saad Ali, Senior Software Engineer at Google and Kubernetes storage special interest group (SIG) lead, told eWEEK. “Kubernetes support of CSI was introduced in Kubernetes as alpha in 1.9 and has been promoted to beta in 1.10, meaning it is moving rather quickly.”
Kubernetes was first developed by Google and has been operated as a hosted project managed by the Cloud Native Computing Foundation (CNCF) since July 2015. The Kubernetes 1.10 milestone is the first release of 2018 and follows the Kubernetes 1.9 update that became generally available in December 2017. Kubernetes is now supported by the largest public cloud providers, including Amazon, Google and Microsoft and benefits from a large community of vendor and developer contributions.
Ali noted that new features generally take at least three releases to go from alpha to stable. This feature development timeline allows Kubernetes developers to get feedback and iterate on the designs, with the end goal of delivering high quality, production grade features, he noted.
With CSI, the goal is to provide a storage abstraction layer, that makes it easier for different storage systems to plug into a Kubernetes deployment. Ali explained that as far as end users are concerned, all existing storage volume plugins will continue to work as they do today, under the CSI model.
“Even when some of the in-tree volume plugins are migrated to out-of-tree CSI plugins, in future releases, the change will be invisible to end users since it will not change the API that users use to consume volume plugins,” Ali said.
Among the features that have landed in the Kubernetes 1.10 update is Kubelet TLS Bootstrap which is designed to improve the use of encryption for data running on a Kubernetes node (kubelet). TLS Bootstrap has been in various stages of development in Kubernetes since at least the 1.4 release that came out back in October 2016.
“This is really useful in clusters that make use of features like cluster autoscaling where nodes may come and go as load increases or decreases,” Derek Carr, lead engineer for Kubernetes at Red Hat, told eWEEK.
Carr said that Red Hat wants to automate more functions around management of the node hosts in a Kubernetes cluster and the Kubelet TLS Bootstrap feature is a critical step in that journey, as it simplifies the automated addition of new hosts in Red Hat OpenShift clusters. OpenShift is Red Hat’s container management platform that is based on Kubernetes. Carr added that future improvements are planned for TLS Bootstrapping in upcoming Kubernetes releases.
“In particular, the ability for the kubelet to automatically rotate both its client and server certificates used to communicate with the API server prior to those certificates expiring is a particularly exciting next step,” Carr said.
Kubernetes 1.10 also integrates a fix for the CVE-2017-1002101 security vulnerability, which was first publicly disclosed on March 12. The flaw could have enabled arbitrary file access from a container to the host file system.
Tim Allclair, Senior Software Engineer at Google and lead of the authentication SIG at Kubernetes said that more details on the response to Kubernetes security issues will be coming in a future blog post.
“For long term mitigation, I’m investigating new volume architectures in the context of secure pod isolation that would ensure these types of issues wouldn’t be exposed in that environment,” Allclair told eWEEK.
Carr added that the Kubernetes community is also investigating additional steps, such as a bug bounty program, to attract more security researchers to look at the code, shakeout any security bugs and continuously improve the security posture of the project as a whole.
“Keep in mind identification is only one part of the problem, we also need the remedy,” Carr said. “Here too Kubernetes pulled from its vast contributors and Red Hat, in particular, was able to allocate time and resources to help the community remedy for the CVEs faster than would have otherwise been possible.”
“We all share a common goal and we can leverage each other to make Kubernetes as secure as possible,” Carr said.