Kubernetes Security: The Two-Question Test
As we approach KubeConEU 2023, it’s useful to look back at all the progress that’s been made with Kubernetes since the original KubeCon in 2015. We’ve seen the project mature over 26 releases. We’ve seen new functionality added (StatefulSets, Operators, ClusterAPI, etc.), new extensibility added (e.g. CRDs, CRI, CNI, CSI, etc.) and the ecosystem around Kubernetes has exploded in so many ways. From the humble beginnings of a few engineers at Google trying to build a variant of Borg that could be used by open communities to the tens of thousands of people that have attended KubeCon events over the years, it’s been incredible to watch the Kubernetes community grow.
And even with all that growth, there’s one question that always seems to confuse people that come to Kubernetes from other technology domains – “Why doesn’t Kubernetes include [XYZ technology] in the platform?” And the [XYZ technologies] discussions always focus on a few areas:
- A complete security solution
- A complete developer experience
- A life cycle management framework for the applications and code.
These are fair questions to ask, but it’s useful to have some historical context to understand why the Kubernetes project explicitly chose not to include those functionalities. Before Kubernetes became a public project, the industry was working through integrated-stack projects with overly complex scope (e.g. OpenStack) or integrated-stack projects that were primarily driven by a single vendor (e.g. Cloud Foundry, Docker). Kubernetes chose to focus on including certain infrastructure platform capabilities and then to allow other projects to focus on technologies further up the stack. This allowed the project to stay focused on core platform capabilities while allowing the ecosystem to build interesting services that could run on top of the platform.
When looking at Kubernetes security, it does not include “a complete security solution” within the project. It does provide some security functionality as outlined in this 4Cs of Cloud Native security explainer – Kubernetes RBAC, PodSecuritySpec, Kubernetes Ingress with TLS, Network Policies, etc. When I speak with people and companies about Kubernetes and security, I tend to ask two questions:
- Do you run/operate Kubernetes?
- How do you secure the applications running on your Kubernetes clusters?
The reason I ask question one is to understand if they are part of the cloud platform team (or platform engineering) or if they are more focused on the applications before they are running in production. The latter would include teams responsible for container registries, CI/CD systems, code repositories, QA testing, etc.
The answer to that question also tells me if they are focused on things like cluster or multi-cluster deployments, identity management, automation, security, high availability, etc.
The reason I ask question two is to better understand how they think about security and how it can impact both the application teams and the cloud platform teams. Since Kubernetes doesn’t inherently include a complete security solution for the applications, this creates a situation where the application teams have a choice about how applications will be secured. By themselves, they could choose to embed distributed security code into each application or microservice. This has the advantage of allowing the application teams to control and own their application security. But it also has the disadvantage of forcing application teams to be security experts, to maintain security code instead of focusing on business logic and coordinate with other teams about how cross-application security will work. This added work on application teams can quickly become burdensome, especially if different teams choose to use different programming languages or don’t have well-established lines of communication in place to coordinate security architectures, protocols, policies, etc.
The alternative approach to security for applications running on Kubernetes is a service mesh, such as Istio. The service mesh provides a layer of network abstraction where security, high availability and observability can be embedded within each Kubernetes cluster. Within the service mesh, that distributed application logic can be programmed, through a series of policies, to offload application security to the network layer. This allows cloud platform teams to centrally manage security policies that can be applied to all applications.
While a service mesh can provide a wide range of capabilities for a Kubernetes cluster, the most commonly used is to enable a zero-trust security (ZTS) architecture. This means that identity management (authentication, authorization) and traffic encryption (e.g. mTLS) can be managed by the service mesh, simplifying day-to-day operations for application teams – they don’t even have to think about it.
And one of the most exciting things happening in the world of service mesh is the next-generation architecture for Istio, called Istio Ambient Mesh. Ambient Mesh significantly reduces the complexity and overhead of enabling security for Kubernetes environments. It enables ZTS by default on all nodes running in a Kubernetes cluster and reduces the computing overhead of running the mesh by up to 90%. And the best news is that it was recently merged into the main Istio project, part of the CNCF, which means that it gets the full support of that vibrant community of developers.
So if you’re looking for “a complete security solution” for Kubernetes, and you answered ‘yes’ to both of those questions, then Istio Ambient Mesh should be at the top of your list of things to explore this KubeCon season. Not only will your developers thank you, but you’ll be making security highly scalable for your Kubernetes applications.