Instead of going through the process of replacing expired certificates that’s documented, is it true that if you just upgrade Linkerd it will update all the certificates as well? Could you write a script to automate the upgrade code for Linkerd is bash or cloudformation?
Hi @sabrinaGPS . Unfortunately no, upgrading Linkerd is a separate activity from updating or rotating the TLS issuer and trust anchor it uses. Upgrades are designed to be zero downtime, in-place operations, so they don’t replace or otherwise interfere with any existing TLS credentials.
So either way you’ll need to decide how to manage your TLS chain, whether that’s “set all credentials to a 100-year lifetime so that I never have to think about it again” to “automatically rotate everything as frequently as possible” to something in between.
in terms of automating upgrades for Linkerd, every release tends to be different. Some are very straight-forward and others (stable releases) can introduce breaking changes that require users to do some work. Our Linkerd Enterprise distribution provides lifecycle automation that covers all of this and more, but even in open source we document everything you need to know for every release.
Hope that helps!
So I have Linkerd already installed and I used the CLI command to install it. Which documentation would I follow to manage he TLS chain? Would I need to reinstall Linkerd? Is rotating the TLS and trust anchor all done at the same time or is it two different processes?
You don’t need to reinstall Linkerd to rotate the certificates. There are docs for automatically or manually rotating the certificates.
Additionally we typically recommend using Helm for production installs, as it allows you to manage the config in a declarative way. Installing Linkerd with Helm | Linkerd
For the duration and renew before can you explain that alittle more. And what’s the longest time it can go. Does it have to match up with if we went out 100 years on the trust ancho?
Hi @sabrinaGPS , the best place to understand those fields is in the cert-manager documentation.
There is no requirement that the issuer certificates (which are per cluster) and the trust anchor (which is across clusters) have the same lifetimes.
I don’t know what the longest possible value of a certificate lifetime is. That’s an interesting question. I’m pretty sure I’ve seen 10 years in practice. Let me know if you find the answer…