Service Mesh Demand for Kubernetes Shifts to Security
DETROIT — Service mesh has long been considered an essential staple in creating, deploying, and managing Kubernetes environments. However, as the community becomes more aware of the threats and challenges associated with managing highly distributed containerized environments, security has emerged as the main benefit of what service mesh offers DevOps teams.
According to a survey Buoyant conducted of KubeCon + CloudNativeCon Europe attendees, security remains the key driver behind service mesh adoption.
The idea, Linkerd creator William Morgan, CEO of Buoyant, told The New Stack is that Buoyant Cloud will now be able to automate Linkerd upgrades, installations, rollbacks, data-plane version syncs, etc. Morgan’s creative philosophy for Linkerd also seems to continue to carry over from the early days of Twitter when Morgan’s fellow Twitter engineers sought a way to simplify scaling the platform to accommodate hundreds of millions of users, which lead to Linkerd’s creation. Morgan spoke with The New Stack at the KubeCon + CloudNativeCon North America event here.
“The number-one driver Linkerd these days is the security feature. That was surprising for us because when we came into service mesh as platform engineers, we thought Linkerd in the early days was about observability and traffic control, which are still useful, of course,” Morgan said. “Sometimes they’re almost apologetic, but I tell them they don’t have to be apologetic because it makes sense.”
Mutual Transport Layer Security (mTLS), which is TLS, but also helps to ensure that the client is authenticated. TLS is a connection-level protocol designed to provide security for a TCP connection, Morgan explained. (We’ll see exactly what security means here below). Since TLS works at the connection level, it can be combined with any application-level TCP protocol without that protocol needing to do anything different, Morgan wrote in a blog post. For example, HTTPS is HTTP combined with TLS (the “S” in HTTPS refers to SSL, the predecessor of TLS), and nothing about HTTP needs to change to accommodate TLS.1, Morgan wrote.
The three guarantees for a connection that TLS provides that Morgan communicated include:
- Authenticity: the parties on either side can prove that they are who they say they are.
- Confidentiality: no one else can see what data is being exchanged.
- Integrity: the data received is the same data that was sent.
“MTLS is a very well-understood protocol. It’s got its warts and it has its detractors, and there are no surprises there,” Morgan told The New Stack. “But that’s the standard that we have available and so let’s make that work for use.”
In this era of DevOps hoping to achieve or implement zero trust security into their operations, the sidecar component of service mesh will remain critical, Morgan said. The sidecar is seen as a key component of the service mesh. It connects — or more exactly — interconnects microservices to different distributed containers and virtual machines. It also serves a key function with service mesh for connecting microservices in Kubernetes environments, serving as a gateway in many ways. However, Solo.io and Google recently introduced Istio Ambient Mesh, which company representatives claim is the industry’s first service mesh to deliver both sidecar or sidecar-less architectures while maintaining the key security features the service mesh offers.
However, without mentioning Istio Ambient Mesh, Morgan noted that in a “zero trust world,” the service mesh sidecar becomes “really more interesting,” amid the “sidecar-less buzz.”
“The whole point of zero trust is, every part of your infrastructure is doing its own validation, authentication and authorization,” Morgan said. “But without the sidecar so that the proxy is the enforcement point, security boundaries get fuzzier as you move out of the sidecar model.”
