Automatic mTLS

By default, Linkerd automatically enables mutual Transport Layer Security (mTLS) for most HTTP-based communication between meshed pods, by establishing and authenticating secure, private TLS connections between Linkerd proxies. This means that Linkerd can add authenticated, encrypted communication to your application with very little work on your part. And because the Linkerd control plane also runs on the data plane, this means that communication between Linkerd’s control plane components are also automatically secured via mTLS.

Not all traffic can be automatically mTLS’d, but it’s easy to verify which traffic is. See Caveats and future work below for details on which traffic cannot currently be automatically encrypted.

How does it work?

In short, Linkerd’s control plane issues TLS certificates to proxies, which are scoped to the Kubernetes ServiceAccount of the containing pod and automatically rotated every 24 hours. The proxies use these certificates to encrypt and authenticate most HTTP traffic to other proxies.

To do this, Linkerd maintains a set of credentials in the cluster: a trust anchor, and an issuer certificate and private key. These credentials are generated by Linkerd itself during install time, or optionally provided by an external source, e.g. Vault or cert-manager. The issuer certificate and private key are placed into a Kubernetes Secret. By default, the Secret is placed in the linkerd namespace and can only be read by the service account used by the Linkerd control plane‘s identity component.

On the data plane side, each proxy is passed the trust anchor in an environment variable. At startup, the proxy generates a private key, stored in a tmpfs emptyDir which stays in memory and never leaves the pod. The proxy connects to the control plane’s identity component, validating the connection to identity with the trust anchor, and issues a certificate signing request (CSR). The CSR contains an initial certificate with identity set to the pod’s Kubernetes ServiceAccount, and the actual service account token, so that identity can validate that the CSR is valid. After validation, the signed trust bundle is returned to the proxy, which can use it as both a client and server certificate. These certificates are scoped to 24 hours and dynamically refreshed using the same mechanism.

Maintenance

The trust anchor generated by linkerd install expires after 365 days, and must be manually rotated. Alternatively you can provide the trust anchor yourself and control the expiration date.

By default, the issuer certificate and key are not automatically rotated. You can set up automatic rotation with cert-manager.

Caveats and future work

There are several known gaps in Linkerd’s ability to automatically encrypt and authenticate all communication in the cluster. These gaps will be fixed in future releases:

• Non-HTTP traffic is not currently automatically TLS’d. This will be addressed in a future Linkerd release.

• HTTP requests where the Host header is an IP address, rather than a name, are currently not automatically TLS’d. For example, the connections that Linkerd’s Prometheus control plane component uses to scrape proxy metrics are not currently automatically TLS’d. This will be addressed in a future Linkerd release.

• Linkerd does not currently enforce mTLS. Any unencrypted requests inside the mesh will be opportunistically upgraded to mTLS. Any requests originating from inside or outside the mesh will not be automatically mTLS’d by Linkerd. This will be addressed in a future Linkerd release, likely as an opt-in behavior as it may break some existing applications.

• Ideally, the ServiceAccount token that Linkerd uses would not be shared with other potential uses of that token. In future Kubernetes releases, Kubernetes will support audience/time-bound ServiceAccount tokens, and Linkerd will use those instead.