diff --git a/.github/workflows/check.yml b/.github/workflows/check.yml index 31a9cdf089..4c5e6fd831 100644 --- a/.github/workflows/check.yml +++ b/.github/workflows/check.yml @@ -10,7 +10,7 @@ jobs: name: check source files runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 - name: Markdown SEO Check uses: zentered/markdown-seo-check@v1.1.2 with: diff --git a/.github/workflows/install.yml b/.github/workflows/install.yml index 9670278174..3ca2e0aaed 100644 --- a/.github/workflows/install.yml +++ b/.github/workflows/install.yml @@ -30,13 +30,13 @@ jobs: runs-on: ubuntu-latest steps: - name: Checkout code - uses: actions/checkout@v3 + uses: actions/checkout@v4 - name: Build scripts run: | make build-run.linkerd.io - - uses: actions/upload-artifact@v3.1.2 + - uses: actions/upload-artifact@v3.1.3 with: name: run.linkerd.io path: tmp/run.linkerd.io/public diff --git a/linkerd.io/content/_index.md b/linkerd.io/content/_index.md index 3ba66a4d36..569ac06f31 100644 --- a/linkerd.io/content/_index.md +++ b/linkerd.io/content/_index.md @@ -8,7 +8,7 @@ keywords: outputs: - html announcement_banner: - description: "2023-08-23 [Announcing Linkerd 2.14 with enterprise multi-cluster and Gateway API conformance! ![Read now](/uploads/announcement-banner-learn-more.svg)](/2023/08/23/announcing-linkerd-2.14/)" + description: "2023-11-07 [Mesh expansion and SPIFFE support arriving in the upcoming Linkerd 2.15! **Read more »**](/2023/11/07/linkerd-mesh-expansion/)" top_hero: title: The world's most advanced service mesh description: Enterprise power *without* enterprise complexity. Linkerd adds diff --git a/linkerd.io/content/blog/2023/1107-mesh-expansion.md b/linkerd.io/content/blog/2023/1107-mesh-expansion.md new file mode 100644 index 0000000000..2851c0a5e9 --- /dev/null +++ b/linkerd.io/content/blog/2023/1107-mesh-expansion.md @@ -0,0 +1,163 @@ +--- +title: 'Mesh expansion and SPIFFE support arriving in the upcoming Linkerd 2.15' +author: 'william' +date: 2023-11-07T00:00:00+00:00 +thumbnail: /images/serena-repice-lentini-IgoMDFTKF-U-unsplash.jpg +draft: false +featured: false +slug: linkerd-mesh-expansion +tags: [Linkerd] +--- + +![A fast-moving clock](/images/serena-repice-lentini-IgoMDFTKF-U-unsplash.jpg) + +In the upcoming 2.15 release, I'm happy to report that we'll be shipping both +mesh expansion and support for SPIFFE and SPIRE. We've heard from many Linkerd +adopters over the past 6 months who've let us know that these features are a +priority for them, and we've been working hard to deliver them with all the +simplicity and security that you've come to expect from Linkerd. + +This work on Linkerd is jointly sponsored by Buoyant (creators of Linkerd) and +by SUSE, who have [recently announced a partnership on this +topic](https://buoyant.io/blog/suse-rancher-and-buoyant-team-up-to-provide-secure-edge-deployments). + +In this blog post I want to describe what these features are, why we're adding +them to Linkerd, and how we tackled some of the design decisions behind the +scenes. + +## What is mesh expansion? + +Mesh expansion is the ability to run Linkerd's dataplane outside of the +Kubernetes cluster, allowing you to bring non-K8s workloads, including legacy +applications running on VMs, into the mesh. Once in the mesh, all communication +to and from these non-Kubernetes applications get the same security, +reliability, and observability features that Linkerd provides for on-cluster +resources, including encryption, authentication, authorization using true +workload identity (not IP address!), retries, timeouts, latency-aware load +balancing, failover, and more. + +In short: mesh expansion means Linkerd will support non-Kubernetes workloads, a +major step forward for the project. And a major challenge for the project as +well. + +Happily, Linkerd has one big advantage in tackling mesh expansion, stemming from +an early design decision. In Linkerd, the "dataplane" refers to Linkerd's Rust +_microproxies_, which handle the actual sensitive information traveling between +application components. These microproxies are actually not Kubernetes-specific +at all. They _are_ specific to Linkerd, i.e. they're not general-purpose +proxies, but they don't know anything about Kubernetes; they don't talk to the +Kubernetes API; and they don't have any requirements about being run on a +Kubernetes cluster or even in a container. Linkerd's microproxies are delivered +as static binaries which can be compiled for a variety of architectures and +platforms, meaning that they can run on almost any machine in the world +(including ARM64, which Linkerd has supported for years.) + +(This microproxy approach is also what makes Linkerd unique in the service mesh +space, and allows it to deliver all the security and operational benefits of a +sidecar approach without the drawbacks found in other service mesh projects. +I've written a lot about this in [my writeup on eBPF vs +sidecars](https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh).) + +So for Linkerd, at least, running the proxies outside of Kubernetes is easy. But +that is just one small part of a much larger set of requirements for mesh +expansion. + +## What does mesh expansion require? + +The biggest challenge for mesh expansion is that, as you might expect, +Kubernetes is no longer available to provide the infrastructure we can build on! +In our design process for mesh expansion, we uncovered four key areas to this +problem: + +* **Identity.** Linkerd needs to provide a secure workload identity for + everything in the mesh. Linkerd's security model follows the mantra of "don't + trust the network" and this means that, unlike the NetworkPolicy approach + found in CNIs, it cannot rely on IP addresses as a form of identity. (I've + written about this in [my guide to zero trust network security for + Kubernetes](https://buoyant.io/resources/zero-trust-in-kubernetes-with-linkerd).) + In Kubernetes, we can use ServiceAccounts as core identity, but outside of + Kubernetes we need another solution. +* **Network connectivity.** Inside a Kubernetes cluster, Linkerd can assume we + have direct connectivity between any proxy and Linkerd's control plane. + Outside of Kubernetes, we need some guaranteed way to establish a connection + from the proxy to the control plane. +* **Runtime.** In Kubernetes we can make use of tools like mutating admission + controllers to automatically inject the sidecar microproxy into workloads that + need to be meshed, and on init containers (and soon, sidecar containers—see my + writeup on [Kubernetes's new sidecar container feature and what it + enables](https://buoyant.io/blog/kubernetes-1-28-revenge-of-the-sidecars)) to + handle L4 networking setup so that all traffic to the pod is transparently + routed through the data plane. Outside of Kubernetes, we need some equivalent + to this functionality. +* **Service discovery**. Inside Kubernetes, we can rely on the built-in DNS + system to give us information about any service that an application wants to + connect to. And when the endpoints for a service change, Kubernetes gives us + ways of keeping up to date with new endpoints and removing old, stale, and + unhealthy endpoints. Outside of Kubernetes, we're on our own. + +Each of these is a distinct and non-trivial challenge, and for Linkerd to have +mesh expansion, each needs to be solved. + +For the purposes of this blog post, the most interesting of these challenges to +discuss is the first one: identity. This is because the solution that Linkerd is +embracing involves another CNCF project called SPIFFE. + +## What are SPIFFE and SPIRE? + +[SPIFFE](https://spiffe.io) is a standard for machine identity, and SPIRE is an +implementation of that standard. What that means is that, if you have an +arbitrary workload on an arbitrary machine, SPIFFE gives you a format for +communicating an identity for that workload that can be used for +security-critical activities such as authentication and authorization. And if +you want to start providing SPIFFE-compatible certificates in a secure way, +SPIRE is a piece of software that will produce these ids for arbitrary +workloads. + +The astute reader will notice that this is exactly the identity-related +challenge that Linkerd faces when extending the mesh to non-Kubernetes +workloads. And in fact, SPIFFE is based on X.509 certificates—the exact same +type of credentials used by TLS, including by Linkerd's on-by-default mutual TLS +which forms the basis of many of its security guarantees. + +So it's a great fit: Linkerd needs a non-Kubernetes-specific mechanism for +determining workload identities, and SPIRE provides exactly that, using a format +that can be plugged right into Linkerd's existing mTLS infrastructure. + +## So what does this mean for me? + +In short, if you are a Kubernetes adopter with "legacy" (read: non-Kubernetes) +workloads that run on Linux-based systems, whether VM or bare metal, Linkerd +2.15 will allow you to communicate between those systems and your Kubernetes +applications in a way that's secure, reliable, and observable, all without +requiring changes to your applications. + +This means you can extend Linkerd's new model of networking—where every +connection is encrypted and authenticated, and every HTTP and gRPC request +delivered in a reliable and latency-optimized way—to your entire stack, not just +the portion that runs on Kubernetes. + +## When will these amazing features be available in Linkerd? + +We're already in late-stage prototype and design, and are currently estimating +Linkerd 2.15 will arrive with these features early next year. + +If you're at Kubecon NA in Chicago this week, please swing by and meet several +Linkerd maintainers who are in attendance at the Linkerd project pavilion as +well as the Buoyant and SUSE expo hall booths. We'd love to dig into your +requirements for mesh expansion and more, and even just to say hi. + +## Linkerd is for everyone + +Linkerd is a graduated project of the [Cloud Native Computing +Foundation](https://cncf.io/). Linkerd is [committed to open +governance.](/2019/10/03/linkerds-commitment-to-open-governance/) If you have +feature requests, questions, or comments, we'd love to have you join our +rapidly-growing community! Linkerd is hosted on +[GitHub](https://github.com/linkerd/), and we have a thriving community on +[Slack](https://slack.linkerd.io/), [Twitter](https://twitter.com/linkerd), and +the [mailing lists](/community/get-involved/). Come and join the fun! + +_(Photo by [Serena Repice +Lentini](https://unsplash.com/@serenarepice?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash) +on +[Unsplash](https://unsplash.com/photos/brown-octopus-IgoMDFTKF-U?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash).)_ diff --git a/linkerd.io/content/blog/_index.md b/linkerd.io/content/blog/_index.md index 8ec46e6b44..d8d7a1aca0 100644 --- a/linkerd.io/content/blog/_index.md +++ b/linkerd.io/content/blog/_index.md @@ -7,8 +7,8 @@ tags: - Tutorials & How-To's - Video items: + - blog/2023/1107-mesh-expansion.md - blog/2023/1011-cve-2023-44487.md - - blog/2023/0720-flat-networks.md -description: Read the latest blog posts covering the Linkerd service mesh, from technical tutorials to announcements to what’s next on the roadmap. +description: The latest blog posts on the Linkerd service mesh, from technical tutorials to announcements to what's next on the roadmap. keywords: [] --- diff --git a/linkerd.io/static/images/serena-repice-lentini-IgoMDFTKF-U-unsplash.jpg b/linkerd.io/static/images/serena-repice-lentini-IgoMDFTKF-U-unsplash.jpg new file mode 100644 index 0000000000..6c0e961d38 Binary files /dev/null and b/linkerd.io/static/images/serena-repice-lentini-IgoMDFTKF-U-unsplash.jpg differ