Service mesh and the CISO [Q&A]

The number of use cases for Kubernetes is expanding as an increasing number of enterprises across a wide array of industries are adopting it as their platform of choice. However, this also expands the enterprise attack surface and business risk as a result.

We spoke to William, Morgan CEO of Buoyant, about how CISOs are coming face-to-face with the insecurity that can arise from managing Kubernetes platforms. They are beginning to see the risks that can unfold as well as how a service mesh can support a security stack.

BN: Which industries are beginning to adopt Kubernetes as their platform of choice and why are we seeing this rise?

WM: In our experience, Kubernetes adoption spans industries, and it's more a question of whether an organization is investing in their infrastructure stack than which industry they're in. We see Linkerd adoption -- which requires Kubernetes as a precondition -- everywhere from banks (including both traditional and 'internet banks') to food service companies to health insurance and medical diagnostics and equipment companies. Even video games get involved -- the Microsoft Xbox Cloud team gave a talk at Kubecon this year about their massive Linkerd deployment on Kubernetes clusters around the world, with the primary value of Linkerd being the layer of security it provided based on mutual TLS.

BN: In what ways does this expand the enterprise attack surface and business risk as a result?

WM: Like all new technology, Kubernetes introduces new operational and security surface areas. While it's a massive improvement from what came before, it's also a massive change, and that means that the techniques, lessons, and tools that served organizations well in the pre-Kubernetes days don't necessarily translate.

BN: What risks should CISOs be keeping in mind when it comes to the insecurity that can arise from managing Kubernetes platforms and how can service mesh support their security stack?

WM: I would argue that the security benefits provided by a service mesh like Linkerd don't address issues that arise from managing Kubernetes platforms itself such much as they address security issues that are fundamental to cloud adoption in the first place. Encryption of data in transit between application components is a great example of this. In the pre-cloud era, the risk factors around internal networking was very different. Organizations owned their own networking infrastructure and exert significant control over it, even down to the keys to the cages that protected the racks in the datacenter. In the cloud environment, that level of control is now out the window -- the networking infrastructure is operated by a third party and shared with other tenants. What we lost in control over our hardware must now be regained via our software, and things like encryption of data in transit are suddenly much more important. And Kubernetes provides us mechanisms by which we can build tools like service meshes, which allow us to transparently inject strong encryption -- and authentication, and authorization -- between application components in a way that is easier and far more seamless than ever before.

BN: How does service mesh support a zero trust approach to modern networking and infrastructure and contain security boundaries?

WM: Zero trust is one of the absolute clearest use cases for a service mesh -- at least, a sidecar-based service mesh. The goal of zero trust is to verify everywhere, all the time, and to do this at the most granular level possible. The service mesh approach tackles this directly by placing a sidecar proxy in each Kubernetes pod. This sidecar proxy then becomes the security enforcement point of the pod, doing its own authentication, authorization, encryption, etc., and contains all the cryptographic key material necessary just for that pod. In Linkerd, our sidecar proxies are written in the Rust programming language which is designed for security and avoids a whole class of CVEs endemic in languages like C++. The sidecar approach means that Linkerd can be transparently added to any Kubernetes application, typically without any additional configuration, and immediately start providing a layer of authorization and authentication based on mutual TLS.

BN: How can CISOs minimize security threats (breaches) and mitigate risk?

WM: The bad news for CISOs is that Kubernetes introduces brand new operational and security models that they must now contend with. The good news is that Kubernetes also makes many things significantly easier for CISOs, especially around addressing security risks that are inherent to the cloud -- which makes sense, since Kubernetes is the pillar of the 'cloud native' approach that is designed for this environment. The service mesh is a great example of that. However, at the macro level the story remains the same for CISOs regardless of Kubernetes: to minimize security threats and mitigate risk, the CISO must have clearly defined threat models; must provide defense in depth; and must stay abreast of the rapidly-changing ecosystem of both threats and mitigations, and must find ways to accomplish that without slowing down the pace of business innovation. For CISOs, Kubernetes may change the details, but does not ultimately change the big picture.

Photo credit: Den Rise / Shutterstock