Linkerd: Up and Running

Chapter 8. Linkerd Policy: Overview and Server-Based Policy

Microservices applications, as we discussed in Chapter 7, require a different level of network security than more traditional monoliths. mTLS gives you the secure communications and workload identity that you need to start tackling this level of network security—but it’s Linkerd’s policy mechanisms that provide the ability to use that identity to control how workloads can talk to each other in your environment.

Linkerd supports two kinds of policy mechanisms: Server-based and route-based. Since policy is the single most complex area of Linkerd, we’ll provide an overview and cover Server-based policy in this chapter, then tackle route-based policy in Chapter 9.

Linkerd Policy Overview

All Linkerd policy mechanisms are based on explicit authorization: Linkerd starts out assuming that it should allow nothing and must be explicitly told what requests should be allowed. This lines up nicely with the zero trust model and makes it straightforward to reason about permissions, since policy resources are always permitting things to happen.

Don’t panic, though; this doesn’t mean a policy is always a morass of hundreds of resources. Linkerd allows setting a default policy at the cluster, namespace, and Pod levels, with policy settings at more specific levels overriding policy settings at more general levels: Pods override namespaces, which override cluster-wide settings, as shown in Figure 8-1.

Figure 8-1. Different Linkerd default ...