Linkerd 2.19 ships a modernized TLS stack that uses post-quantum key exchange by default, switching the proxy's cryptographic module from ring to aws-lc and adding AES_256_GCM ciphersuite plus ML-KEM-768 key exchange for all meshed pod communication. TLS cipher, key exchange, and signature algorithms are now exposed as metrics. The release also promotes native sidecar support from alpha to beta (enabled via the config.beta.linkerd.io/proxy-enable-native-sidecar annotation) and fixes several smaller bugs, including blocking connections to undefined clusterIP Service ports, discovery staleness in native-sidecar mode, a control-plane panic on invalid hostnames, and an issue with invalid podSelectors breaking Server resource processing.
Table of contents
Related announcementsPost-quantum TLSOther fun stuffGetting your hands on Linkerd 2.19Linkerd is for everyonePhoto creditQuestions this post answers
What changed in Linkerd 2.19's TLS implementation for post-quantum security?
Linkerd 2.19 switches its proxy's core cryptographic module from ring to aws-lc and enables the AES_256_GCM ciphersuite along with the post-quantum ML-KEM-768 key exchange algorithm by default for all communication between meshed pods. TLS cipher, key exchange, and signature algorithm details are also now exported as standard metrics for visibility. Track service mesh security upgrades like this one on daily.dev before rolling changes into production.
How do I enable native sidecars in Linkerd 2.19?
Native sidecar support is promoted from alpha to beta in Linkerd 2.19 and can be enabled by setting the config.beta.linkerd.io/proxy-enable-native-sidecar annotation. Native sidecars were first supported in Linkerd 2.15 and rely on the Kubernetes native sidecar containers feature, which graduated to stable in Kubernetes as of April. This addresses long-standing sidecar issues with Jobs and container startup race conditions. Developers weighing Kubernetes sidecar strategies can follow feature maturity updates like this on daily.dev.