The Kubernetes privilege escalation flaw: Innovation still needs IT security expertise

Editorial Note: While not fully discussed in this post, there is a component to this vulnerability that results in unauthenticated remote code execution, in addition to the privilege escalation noted.  You can find more details from our vulnerability article which discusses the specifics of the flaw in more detail.

IT security matters at every level of the enterprise technology stack, from the foundation of the infrastructure up through to the mission-critical applications and services exposed to end users. This need persists regardless of whether a technology is commoditized or at the leading edge - in short, IT security always matters.

For open source software that is often pushing innovations used by modern organizations, such as Linux, hybrid cloud, container, and Kubernetes technologies, this balance between innovation and security and stability is a significant part of the value a Red Hat subscription can offer. Security flaws can occur in any piece of software (or beyond software, as 2018 has taught us well). When they do, Red Hat is committed to delivering as quickly as it can both patches to customers and fixes to upstream open source projects.

Today, we issued a critical Security Advisory and patches for CVE-2018-1002105, a privilege escalation flaw impacting Kubernetes. The Kubernetes privilege escalation flaw provides an example of how Red Hat helps to address software security at both the community and enterprise level, especially as organizations around the world are looking to lean on emerging technologies like Kubernetes to help fuel digital transformation. The de facto standard in Linux container orchestration, Kubernetes makes it possible to orchestrate containerized applications together, enabling composite services comprised of hundreds, or even thousands, of “simpler” services. These orchestrated applications are often easier to manage, more nimble and more straightforward to maintain than traditional applications.

But Kubernetes, like all software, is not immune to security issues - the privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes cluster. This is a big deal. Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall.

It’s important to note that all Kubernetes-based services and products - including Red Hat OpenShift Container Platform, Red Hat OpenShift Online, and Red Hat OpenShift Dedicated - are affected. Red Hat has begun delivering patches and pushed service updates to affected users, enabling them to address this flaw either immediately or when it best fits their specific risk profile. A more detailed account of the Kubernetes privilege escalation flaw can be found here.

This fix is the result of the efforts of the Kubernetes community and leading contributors like Red Hat. But even the act of patching a flaw of this severity brings to light an unpleasant reality, one that Paul Cormier called out just a few months ago: When it comes to open source security, the product/project debate matters, especially for mission-critical systems.

While the Kubernetes community delivered the upstream patch in a timely manner, just having the bits in hand doesn’t necessarily address the other factors impacted by the flaw. What if your production systems are running specialized integration points or workloads that the patch affects adversely? Or what if applying the patch inadvertently causes a performance hit to a production system or, worse, downtime?

This is where open source products can separate themselves from projects. Red Hat has decades of experience in delivering open source products, from hardening code for enterprise requirements to delivering fixes for vulnerabilities and flaws. As the world’s leading provider of open source solutions, we know how to fix issues like this, just like we knew how to fix Spectre, Meltdown, Dirty COW and a host of other flaws before them. Part of this expertise is knowing that it’s not enough to push a fix - we need to provide our customers with the documentation and strategies to help them assess how they are affected, what systems are affected and why (or even why not) they should apply the fixes.

This is the bar that Red Hat has set for itself, first with Linux in the enterprise, and now with enterprise-grade Kubernetes. As Kubernetes becomes more prominent for enterprises as they pursue digital transformation, it stands to reason that more flaws within the technology will be discovered. The community will be ready to fix the code, while Red Hat will be prepared to help you fix your critical systems in a way that can make the most sense for your unique organizational needs.