Buoyant Adds Support for Zero-Trust Policies to Linkerd
Buoyant today announced it has added additional capabilities to both the open source Linkerd service mesh for Kubernetes and the cloud-based management platform it provides to manage instances of the service mesh that make it easier to maintain security.
Version 2.11 of Linkerd adds the ability to enforce security policies via the service mesh as part of an effort to maintain a zero-trust IT environment. In addition to the network policy enforcement features, Linkerd 2.11 also adds support for retries for gRPC calls, a fix for container startup ordering issues and a reduction in the resource utilization for the data plane and control plane.
Buoyant CEO William Morgan says the service mesh provides an ideal platform for enforcing security policies that limit which types of network traffic are allowed into a Kubernetes cluster all the way down to the pod level. Linkerd’s network policies use the cryptographically secure identities provided by the mutual TLS (mTLS) protocol to enable encryption. That approach makes it possible to ensure that access to a sensitive service comes from a specific namespace or service account, adds Morgan.
In contrast, Kubernetes comes with built-in mechanisms for restricting network communication based on, for example, IP addresses that allow IT teams to implement a narrow range of higher-level policies at the cluster level.
At the same time, Buoyant is also making it possible to manage policies and network traffic via Buoyant Cloud. IT teams can manage encryption, identity and authorization of all traffic on Kubernetes via the software-as-a-service (SaaS) platform. IT teams can both manage their policies and monitor the effect they have on the traffic in their clusters. They can also verify policies are in effect for each allowed or attempted type of traffic on their cluster and detect anomalies such as unexpected plaintext traffic or policy violations.
In general, as a lighter-weight alternative to service meshes originally designed for web-scale companies, Morgan says Linkerd continues to gain traction. It’s too early to say whether organizations will standardize on any single service mesh, he adds.
In the meantime, security teams are starting to appreciate service meshes as a level of abstraction above Kubernetes that makes it easier to enforce zero-trust security policies at a more granular level. At a time when many organizations are reviewing their entire approach to security to enforce such policies, a lightweight service mesh makes it easier for IT teams to get approval to deploy Kubernetes clusters in a production environment, notes Morgan.
It’s now only a matter of time before more organizations adopt a service mesh. Originally conceived to help organizations manage application programming interface (API) traffic, many IT teams are starting to view service meshes as a means to give DevOps teams programmatic control over network and security services in a way that doesn’t require them to master a wider range of lower-level APIs.
It may be a while before all the capabilities of a service mesh are fully appreciated. In the meantime, however, there’s no time like the present to start experimenting with a service mesh that doesn’t require a small army of site reliability engineers (SREs) to install and maintain.
