Today we’re happy to announce the release of Linkerd 2.15, which adds support for workloads outside of Kubernetes. This new “mesh expansion” feature allows Linkerd users for the first time to bring applications running on VMs, physical machines, and other non-Kubernetes locations into the mesh, delivering Linkerd’s uniform layer of secure, reliable, and observable connectivity across both Kubernetes and non-Kubernetes workload alike.

The 2.15 release also introduces support for SPIFFE, a standard for workload identity which allows Linkerd to provide a consistent layer of uniform layer of cryptographic identity and authentication to any application, regardless of where it’s running.

Finally, this release introduces some important changes in the way that we’re publishing Linkerd: as of 2.15, we will no longer be producing open source Stable Releases. If you’re running Linkerd in production today, please see the section A new model for stable releases below.

As usual, the 2.15 release includes a massive list of bugfixes and improvements. Read on for details!

Mesh expansion

As we promised last November, Linkerd 2.15 introduces mesh expansion: the ability to deploy Linkerd’s ultralight Rust microproxies anywhere outside of Kubernetes and connect them to a Linkerd control plane running on a Kubernetes cluster. This allows Linkerd to handle non-Kubernetes workloads, upleveling all TCP communication to and from these workloads secure, reliable, and observable. Non-Kubernetes applications get the full set of Linkerd features, including mutual TLS, retries, timeouts, circuit breaking, latency-aware load balancing, dynamic per-request routing, zero trust authorization policies, and much more.

Mesh expansion is an important part of achieving our goal of making Linkerd the universal networking layer for cloud native organizations. While we love Kubernetes, we recognize that even the most sophisticated organizations often still have significant investments in applications that don’t run outside of it. With Linkerd 2.15, regardless of whether your workloads are running on resource-constrained ARM64 edge devices, legacy “big iron” VMs, or physical machines in your server closet, Linkerd’s uniform layer of security, reliability, and observability is at your disposal.

This move was made significantly easier by Linkerd’s core design of ultralight microproxies written in the Rust programming language. The use of Rust, which has “ability to prevent memory-related bugs, manage concurrency, and generate small, efficient binaries” (Why Rust is the most admired language among developers) allows Linkerd not just to avoid the memory vulnerabilities that are endemic to languages like C and C++, but to provide minimal resource footprint and—most importantly—a minimal operational burden to the user. Linkerd’s Rust microproxies are key to its simplicity-first approach, and our ability to deliver small, static binaries which can be compiled for a wide variety of architectures and platforms was key to unlocking Linkerd’s new mesh expansion capabilities. 

SPIFFE support

One major challenge in mesh expansion is how to generate workload identities for non-Kubernetes workloads. To solve this, we introduced support for SPIFFE, a CNCF graduated project that addresses exactly that concern.

Workload identity is central to Linkerd’s approach to communication security. Rather than relying on easily-spoofed IP addresses to identify clients and servers, Linkerd doesn’t trust the network: it secures communication with mutual TLS, which not only encrypts the communication and prevents tampering, but also but cryptographically authenticates the identities of client and server based on unique workload identities. Mutual TLS is a stricter variation of the same well-established protocol (TLS) that powers the majority of the Internet today.

Prior to Linkerd 2.15, Linkerd could simply use the workload’s Kubernetes ServiceAccount to automatically generate a workload identity. Using this pre-existing identity was central to our “zero config zero trust” approach that makes dropping mTLS into an existing Kubernetes application trivial, and we continue to support it in Linkerd 2.15.

For workloads running outside of Kubernetes, however, there are no ServiceAccounts to rely on: only applications running on machines. To solve this, we turned to SPIFFE, a standard hosted by the CNCF, and its reference implementation, SPIRE. These two projects solve the problem of generating secure workload identity for arbitrary processes on arbitrary machines. Linkerd 2.15 generates SPIFFE ids for non-Kubernetes workloads using SPIRE, and these ids can be used alongside Linkerd’s existing ServiceAccount-based ids  as the basis for Linkerd’s zero-trust authorization policies.

With Linkerd 2.15 you can now encrypt all traffic to your VM workloads by default, and add zero-trust controls over all access right down to the level of individual HTTP routes and gRPC methods for specific clients.

Also Read: Three Reasons Why Kubernetes Has Swiftly Become a Crucial Container Orchestration System

A New Model For Stable Releases

In Linkerd 2.15 we’re making some significant changes to the way that Linkerd is delivered.

We will no longer be shipping stable Linkerd releases in open source. Instead, Linkerd 2.15.0 and all future stable releases will be delivered as Buoyant Enterprise for Linkerd (BEL), our enterpris-ready Linkerd distribution. BEL is Linkerd plus a set of additional tools, features, and testing designed for sustained, large-scale production use, and upgrading to BEL releases is trivial.

BEL is free for non-production use, and free for production use at organizations with fewer than 50 employees. Organizations with 50 or more employees must pay to use BEL in production.

This is a big change and we want to make it simple and predictable for everyone with plenty of breathing room. We ourselves are Linkerd operators, devops engineers, and platform owners who operate production systems with Linkerd, and we’d never want anything to get in the way of your core job of delivering the secure, highly-available platform your own businesses rely on.

To support this, these restrictions only go into effect in 90 days, on May 21st, 2024. Organizations that sign up in the next 30 days are also eligible for a substantial discount. We’re also happy to accommodate non-profits, high-volume use cases, and other organizations with unique needs. Please see the FAQ for more details on payments and pricing.

This change is a big one, but it’s absolutely necessary for us to fund the incredible set of features we’re busy adding to Linkerd. We’re tackling significant new work like adding ingress traffic , egress control, IPv6, Windows, eBPF, ambient approaches, and more to Linkerd, and we’re determined to to deliver them with the same ultralight, ultrafast, “just works” approach that makes Linkerd so uniquely today in a space that’s notorious for complexity. Linkerd 2.15 is just a  step in a long journey of compounding value.

To accomplish these lofty goals, we need the companies that are building their businesses on top of Linkerd to do their part to fund the project. This change ensures that they can do that, while giving the thriving ecosystem of startups, developers, and students the ability to use Linkerd without restriction.

Point releases like the upcoming Linkerd 2.15.1, major releases like the upcoming 2.16.0, and backports like the upcoming Linkerd 2.14.10 will also only be published as BEL releases.

We’ll continue publishing edge releases to the GitHub repo as usual. These have always served as a valuable mechanism for early testing and vetting by the community, and we hope to see more of this under this new framework.

The post Announcing Linkerd 2.15: Support for VM workloads, SPIFFE identities, and a new way to get stable releases appeared first on EnterpriseTalk.