Automatic mTLS

    See Caveats and future work below for some details.

    A full definition of mTLS is outside the scope of this doc. For an overview of what mTLS is and how it works in Kuberentes clusters, we suggest reading through .

    Linkerd transparently applies mTLS to all TCP communication between meshed pods. However, there are still ways in which you may still have non-mTLS traffic in your system, including:

    • Traffic on ports that were marked as skip ports, which bypass the proxy entirely.

    You can in a variety of ways. External systems such as Buoyant Cloud can also automatically generate reports of TLS traffic patterns on your cluster.

    The trust anchor generated by the default CLI command expires after 365 days. After that, it must be —a non-trivial task. Alternatively, you can provide the trust anchor yourself and control the expiration date, e.g. setting it to 10 years rather than one year.

    Kubernetes clusters that make use of Linkerd’s must share a trust anchor. Thus, the default linkerd install setup will not work for this situation and you must provide an explicit trust anchor.

    Similarly, the default cluster issuer certificate and key expire after a year. These must be rotated before they expire. Alternatively, you can .

    External systems such as Buoyant Cloud can be used to monitor cluster credentials and to send reminders if they are close to expiration.

    On the control plane side, Linkerd maintains a set of credentials in the cluster: a trust anchor, and an issuer certificate and private key. These credentials can be generated by Linkerd during install time, or optionally provided by an external source, e.g. or cert-manager. The issuer certificate and private key are stored in a ; this 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 which stays in memory and never leaves the pod. The proxy connects to the control plane’s 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 , 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.

    Finally, when a proxy receives an outbound connection from the application container within its pod, it looks up that destination with the Linkerd control plane. If it’s in the Kubernetes cluster, the control plane provides the proxy with the destination’s endpoint addresses, along with metadata including an identity name. When the proxy connects to the destination, it initiates a TLS handshake and verifies that that the destination proxy’s certificate is signed by the trust anchor and contains the expected identity.