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.
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
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
stays in memory and never leaves the pod. The proxy connects to the control
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
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
By default, the issuer certificate and key are not automatically rotated. You
can set up automatic rotation with
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
Hostheader 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.