Linkerd’s FIPS compliance means it’s using cryptographic algorithms approved for use in U.S. federal government systems, which are generally considered more secure and rigorously vetted.
Let’s see Linkerd in action, specifically how it handles TLS between its control plane and data plane components, and then how to enable FIPS mode.
First, imagine a typical Linkerd deployment. The controller pods (like controller-0) in the linkerd namespace are the control plane. The proxy containers within your application pods (e.g., webapp-xxxx) are the data plane. These two sides need to communicate securely, and Linkerd uses TLS for this.
Here’s a snapshot from a running Linkerd control plane pod, showing its TLS configuration:
kubectl exec -n linkerd deploy/controller -- cat /certificates/tls.crt
This command retrieves the certificate used by the control plane. When a data plane proxy needs to connect to the control plane, it will present its own identity certificate and trust the control plane’s certificate.
Now, let’s look at enabling FIPS. This involves configuring the underlying Go standard library, which Linkerd uses for its TLS operations, to only use FIPS-approved cryptographic modules.
To enable FIPS mode for Linkerd, you’ll typically modify the Helm values during installation or upgrade. The key parameter is identity.tls.fipsCompliant.
Here’s how you might set it in a values.yaml file:
identity:
tls:
fipsCompliant: true
When this is set to true, Linkerd will instruct the Go runtime to operate in FIPS mode. This means that all cryptographic operations, including those for generating keys, signing certificates, and performing TLS handshakes, will be restricted to algorithms and modes that have been validated against FIPS 140-2 (or its successor, FIPS 140-3).
For example, if you were to inspect the cipher suites negotiated during a TLS handshake between a FIPS-compliant proxy and the control plane, you would find only those that meet FIPS standards. Older, non-FIPS-approved ciphers like TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA would be excluded. Instead, you’d see suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
The most surprising thing about FIPS mode is that it doesn’t necessarily mean stronger cryptography in terms of raw security strength for all algorithms. It strictly means that the implementation of those algorithms has been validated by a U.S. government-approved testing lab to meet specific security requirements. For instance, a non-FIPS AES-256 implementation might be just as cryptographically secure as a FIPS-validated AES-256, but only the FIPS-validated one is permitted in FIPS-compliant environments. This is less about breaking new cryptographic ground and more about assuring the integrity and reliability of the cryptographic building blocks used by the software.
After enabling FIPS compliance, the next challenge is ensuring that all external services your mesh communicates with also support FIPS-compliant TLS, otherwise, you’ll start seeing TLS handshake failures.