Kubernetes Vulnerability: Why the Vulnerability Proves it is Ready for the Enterprise

In case you missed it – Kubernetes has been in the news this week, announcing the first significant security vulnerability for the platform.

In summary: using a specific kind of network request, a bad actor can establish a connection through the Kubernetes API server to a backend server, allowing the attacker to send requests over the network to the backend server. This can be used to take control of any Kubernetes cluster.

That’s the bad news. And there are plenty of articles out there (here and here) detailing the vulnerability.

The good news – There is much more to the story that everyone may not realize. While I am not trying to make light of this vulnerability, or any other system vulnerability, I wanted to concentrate on a few things instead:

• Kubernetes is Enterprise Ready. So much of the talk over the past few years is that enterprises are ready for containers,and are interested in Kubernetes for container orchestration. But the enterprises lack the level of comfort to migrate their applications and workloads to Kubernetes because it is an open sourced solution. If anything, this event shows that Kubernetes is ready for enterprise class workloads, as there had never been a significant vulnerability before this one in the history of the solution, primarily due to the open nature of the product, and the thousands of engineers dedicated to improving and securing the product. If a company is looking objectively at track records alone, they should be able to trust the solution for their enterprise.
• Open Source Security Works. The patch to the Kubernetes vulnerability was created and deployed within 24 hours of discovery, something nearly all of the major product vendors cannot say. Generally, it can take months for even critical security patches to be released by major software vendors after discovery. In fact, nearly every year, there are security researchers that are forced to go rouge with their finding after discovering a hardware of software vulnerability and reporting it to the company, who then decides to evaluate or sit on it and never release it to the public.
• Containers are the Future. While there have been many infrastructure advances in the tech industry over the past decade, containers offer the promise that application developers and system administrators have been pushing for. With the push to migrate more and more resources to a cloud landing zone of some kind, containers should always be part of the conversation, as they generally can agnostically go from landing zone to landing zone without additional refactoring, extending the lifespan of the workload and reducing TCO of the application.

DXC has always taken an agnostic approach to application transformation and workload migration, and using Kubernetes for enterprise container orchestration is just one of the many paths that we can use to shape and optimize an enterprise’s cloud migration journey. If you have questions about cloud applications or optimizing workloads for the cloud, please reach out to me – I am happy to help!