Service Mesh or Multi-Cloud Application Network (MCAN)?
Two Options for Kubernetes Zero Trust Security
Security vs Agility
Everyone needs a secure application environment to prevent unauthorized access to sensitive data. Everyone also needs an agile application to keep their competitive edge.
Agility requires that apps transition from monolithic to SOA/microservices, where the application parts communicate over a network, as services. Unfortunately, these two needs are at odds with each other, as the microservices network creates a new attack surface over which to access sensitive data.
To mitigate this security risk, app teams have embraced the concept of ‘zero trust’, where they do not implicitly trust users and computers just because they have access to the network. Instead, trust is earned by digitally authenticating and authorizing exactly who can communicate with whom, and then encrypting that communication to prevent x-in-the-middle attacks.
However, zero trust comes at the cost of complexity, and many app teams can’t afford it.
Kubernetes and Service Mesh
It is undeniable that Kubernetes (K8s) has won the container management battle. Almost all new apps are built on K8s.
A large reason for K8s success is that it natively supports the SOA/Microservices architecture. That is, a fundamental part of K8s is that containers (pods) can only communicate via K8s services, and only over the K8s network. However, the concept of ‘zero trust’ predates microservices and K8s.
When ‘zero trust’ was first coined, applications still ran in the wild west of VMs and bare metal, where little was known about the identity of users and machines and attaching to the network was as easy as getting a WIFI password or plugging into the nearest RJ-45.
Pre-Kubernetes, many app teams chose the ‘service mesh’ as a way to achieve zero trust. It was effective, as it brought identity, authentication, and authorization to the wild west. Then came K8s, which fundamentally changed the way that containers communicate, and brought its own order to the application world. With K8s, you get several of the things that a service mesh has to provide; A secure K8s API, a rich set of RBAC (Role Based Access Control) rules, namespace segmentation, and pod and service identity. K8s gave service meshes a bit of an identity crisis and had them searching for how they could provide value in this new K8s world.
A few of the hyperscales (led by Google) became enamored with Envoy and found their ‘service mesh’ niche in the form of a ‘sidecar’ proxy. A ‘sidecar’ pod is a set of functions that you can attach to any pod that gives AuthN/Z and encryption necessary to access shared resources that are part of the service mesh.
You make sure that your sensitive data can only be accessed via the service mesh, and thereby achieve zero trust. However, there is no free lunch, and K8s side car service meshes are complex. So complex that you’ll need a dedicated service mesh team, and it will likely slow down your application DevOps to learn how to operate in a Service Mesh world. Also, sidecars balloon the number of pods and compute resources you need for your app to operate, as each pod requires its own sidecar.
As in anything, more moving pieces equal more chances for things to break. So, many K8s application teams avoided service meshes and attempted to provide security in other ways (secure APIs, for example). Of course, Google has the resources to make a service mesh run smoothly, but many enterprises app teams don’t. So, what options do they have for K8s security?
Application Network, the Simpler Option
For all those enterprises (not named Google) where a ‘service mesh’ is technology overkill, there is a much simpler option to achieve application security and zero trust, the Nethopper's Kubernetes Application Operations Platform feature called Multi-Cluster Application Network (MCAN).
The primary difference between a service mesh and a MCAN is that a service mesh attempts to make every pod smarter (with a sidecar per pod), and a MCAN simply makes the K8s service network smarter. A MCAN only needs one pod, or ‘agent’, per cluster to secure all service communication, so there are far fewer moving pieces compared to a Service Mesh. A MCAN exposes deployments (pods) using native K8s services.
Both Service Mesh and MCAN have a central Certificate Authority and use mTLS to securely communicate between pods. A MCAN is particularly useful in multi-cluster (i.e. multi-cloud) environments, because it can communicate services across K8s cluster boundaries, overcoming K8s ‘multi-cloud’ limitations. A MCAN also brings global load balancing to services, which distribute (balance) services requests across two (or more) clouds, thereby protecting services against cloud or cluster failures and migrations.
By contrast, Service meshes, when used in multi-cloud, often need to be integrated with load balancer, IP gateway, and K8s ingress automation to achieve this. Some service meshes claim ‘multi-cloud’ support, but this is often an afterthought, and not a first class feature that includes load balancing, multi-cluster networking, duplicate IP resolution, etc, like a MCAN addresses out of the box.
It’s important to note that, while there is some overlap, a MCAN and a service mesh can work together to achieve ‘multi-cloud zero trust’ over the internet, whereby the service mesh does its work locally in each cluster, and the MCAN securely connects multiple such clusters together.
If your app uses multiple clusters, consider using a Kubernetes Application Operations Platform with MCAN to simplify and secure your K8s applications.