Automatic mTLS

(See “Caveats and future work” below for details on which traffic cannot beautomatically encrypted.)

NoteLinkerd uses Kubernetes Service Accounts to define service identity. Thisrequires that the feature (on by default) isenabled. See the Kubernetes service accountdocumentationfor more.

Once your service has been added, you can validate that mTLS is enabled byfollowing the .

On startup, the proxy generates a private key for itself. This key is stored ina tmpfsemptyDir whichnever leaves the pod and stays in memory. After the key has been generated, theproxy connects to the control plane’s identity component. This component is aTLS and is used to signcertificates with the correct identity. Proxies validate the connection toidentity by using the trust root, which is part of the proxy container’sspecification as an environment variable.

Identity in Linkerd is tied to the Kubernetes ServiceAccountthat is being used by the pod. Once the proxy has connected to the control plane component, it issues a . The CSRcontains an initial certificate with the pod’s identity set to its serviceaccount and the actual service acount token so that identity can validatethat the CSR is valid. Once all validation has succeeded, the signed trustbundle is returned to the proxy and it can use that when it acts as both aclient and server.

These certificates are scoped to 24 hours and will be dynamically refreshedusing the same mechanism when required.

Caveats and future work

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

• Linkerd does not currently enforce mTLS. Any unencrypted requests insidethe mesh will be opportunistically upgraded to mTLS. Any requests originatingfrom 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-inbehavior as it may break some existing applications.