Linkerd: Up and Running

Chapter 9. Linkerd Route-Based Policy

In Chapter 8, we discussed implementing a Linkerd Server-based policy to enhance the security of the emojivoto application. This policy ensures that Linkerd effectively safeguards the application’s workload, preventing unauthorized workloads from making requests. Suppose we want to go further, though? For example, consider a situation where you have a sensitive application. You need to be certain that only specific ServiceAccounts are allowed to make changes, and only certain others have access to read.

That’s where Linkerd’s route-based policy mechanism comes in. In this chapter, we’ll take a closer look at what route-based policy can do and how to use it.

Route-Based Policy Overview

Route-based policy gives Linkerd a way to express policy that depends not only on which workloads are in play, but also on which specific requests are being made. These specific HTTP requests are identified by using Gateway API HTTPRoute resources to specify matches against the HTTP path, method, headers, etc.—almost anything except the body can be used. Requests are still authenticated using mTLS identities.

Gateway API HTTPRoute resources work by associating one or more parents with one or more rules. When using Gateway API for ingress, the parents of an HTTPRoute will be Gateway resources; however, this doesn’t make much sense when using Gateway API to configure a service mesh. When using HTTPRoutes with Linkerd, the parents will be Services instead, and ...