Any discussion of Kubernetes is best started with an understanding of why we need Kubernetes. Kubernetes helps us manage containers, which dominate application development now because they enable portability, faster application development, and greater independence for developers. Once we started using containers in great volume, we needed a way to automate the setup, tear down, and management of containers – that's what Kubernetes does.
The industry has developed other orchestrators, but Kubernetes has emerged as the de facto standard for container orchestration. As much as nearly a year ago, 69% of organisations surveyed by the Cloud Native Computing Foundation (CNCF) were using Kubernetes to manage containers. Kubernetes started with the technical credibility of coming out of Google, and thousands of contributors have increased the robustness, scalability, and security features of Kubernetes.
A series of data points highlight the growth in popularity of Kubernetes. All the cloud providers offer a managed Kubernetes service. Amazon executives highlighted at the company’s recent AWS re:Invent conference that its managed Kubernetes service, AWS EKS, is the fastest growing service AWS has ever released. KubeCon, the industry conference hosted by the Cloud Native Computing Foundation (CNCF) has doubled in attendance every year, with more than 8000 people attending the recent North America conference. And scan any tech job aggregator like Indeed.com and you’ll see 1000s of companies seeking Kubernetes expertise for their IT architecture teams.
The mergers and acquisitions market provides another lens into the popularity of Kubernetes. IBM’s recent acquisition of Red Hat for $34 billion provides another indication of the popularity of Kubernetes. Most industry analysts said OpenShift, Red Hat’s commercial distribution of Kubernetes, drove a significant portion of that valuation. Also, recently, VMware acquired Heptio, which provided another popular distribution of Kubernetes. The purchase price is rumored to be $550 million, an astonishing amount for a company that hadn’t had the chance to generate much revenue yet.
Common misunderstandings about Kubernetes
Despite the massive popularity of Kubernetes, misunderstandings about the platform persist. One centres around how to work with Kubernetes. Most people running open source software have a “DIY” or “do it yourself” perspective – they’re used to digging into software and tuning all the dials and twisting all the knows. So, people often think they should be working directly in the Kubernetes platform. Often that’s not the best approach, however.
As Kubernetes continues its market dominance, organisations need to look for ways to apply a UI layer to the orchestrator to simplify management and security
Building support for high availability (HA) and resilience into Kubernetes, for example, is complicated – these areas provide a great reason to leverage abstraction layers on top of Kubernetes to simplify its operations and make it run in a more robust manner. People talk about Kubernetes needing a UI layer – another interface into it to make kind of needs a UX layer on top. A lot of the managed Kubernetes services provide this abstraction layer for getting the fundamentals set up, like setting up the master, the API server, and resilient data stores.
The same goes for the security layer. Kubernetes has a lot of power controls built in for networking policy enforcement, for example, but accessing them natively in Kubernetes means working in a YAML file. Having tooling on top that visualises the networking layer, as we do in the StackRox platform, makes the power of Kubernetes far more accessible to enterprises in a way similar to how Google Kubernetes Engine makes the control plane of Kubernetes more accessible.
Securing Kubernetes
Kubernetes provides powerful security capabilities around secrets management and network policy enforcement. Digging into network policy enforcement, you can use Kubernetes to limit what resources each asset can reach. By default, Kubernetes allows all assets to talk to all other assets, because the premise of Kubernetes is that it’s meant to aid application development, and as developers craft the microservices that are the building blocks for applications, Kubernetes defaults to letting all those services communicate.
Because the developers are working in Kubernetes, the security team should also use Kubernetes to help tighten down the environment – to limit those communications paths to reduce the blast radius if an attacker got in. Moving to least privilege is a fundamental tenet of security – any person or asset should be allowed to do only the functions necessary to its role and no more. Look for a container security platform that simplifies the process of moving Kubernetes to a least privilege model. The platform should highlight the allowed communications between assets, simulate new network policies, and recommend updated configurations that support least privilege and harden the environment.
Bringing it all together
As Kubernetes continues its market dominance, organisations should look for ways to apply a UI layer to the orchestrator to simplify functionality such as management and security. Despite its inherence security functions, Kubernetes also increases the attack surface, so organisation should look for security platforms that integrate deeply with Kubernetes to make accessing its security functions easier and provide mechanisms for reducing its attack surface.
Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.