Updated Automatically Rotating Certs Docs #1757
Conversation
…ocess of using cert-manager for entire trust chain Signed-off-by: Alen Haric <[email protected]>
Signed-off-by: Alen Haric <[email protected]>
Signed-off-by: Alen Haric <[email protected]>
| this guide, we'll focus on a self-sufficient setup: we will configure | ||
| cert-manager to act as an on-cluster | ||
| [CA](https://en.wikipedia.org/wiki/Certificate_authority) and have it re-issue | ||
| Linkerd's issuer certificate and private key on a periodic basis, derived from | ||
| the trust anchor. | ||
| the trust anchor. Additionally, we will use trust-manager create a trust bundle |
| commonName: root.linkerd.cluster.local | ||
| isCA: true | ||
| duration: 87600h0m0s | ||
| renewBefore: 87264h0m0s |
There was a problem hiding this comment.
Huh. I had thought this was "renew, at latest, when this many hours are remaining"?
There was a problem hiding this comment.
you're correct. updating to clarify.
There was a problem hiding this comment.
just double checked their docs: https://cert-manager.io/docs/usage/certificate/#reissuance-triggered-by-expiry-renewal
It looks like the original blurb we had on the site originally (where I copied this blurb from) is accurate: "If spec.renewBefore has been set, it will be spec.renewBefore amount of time before expiry. cert-manager will set Certificate's status.RenewalTime to the time when the renewal will be attempted."
| - server auth | ||
| - client auth | ||
| duration: 28h0m0s | ||
| renewBefore: 25h0m0s |
There was a problem hiding this comment.
Same question as above re renewBefore, but also, duration should be 48 hours, correct?
| As a first step, | ||
| [install cert-manager on your cluster](https://cert-manager.io/docs/installation/) | ||
| and create the namespaces that cert-manager will use to store its | ||
| webhook-related resources. For simplicity, we suggest using the default | ||
| namespace linkerd uses: |
There was a problem hiding this comment.
Should we refer to the main doc above rather than duplicating the basic setup twice?
There was a problem hiding this comment.
I'm open to it either way. I originally did it this way b/c we have some customers who only set up one and not the other (in both directions), so I wanted both be standalones, but if you think it makes more sense not to duplicate the instructions I'm more than happy to just ref the mTLS doc
| ## Create Linkerd webhook issuer | ||
|
|
||
| Using the previously-generated trust root certificate, create a separate | ||
| `ClusterIssuer` for Linkerd webhook certificates: | ||
|
|
||
| ```bash | ||
| kubectl apply -f - <<EOF | ||
| apiVersion: cert-manager.io/v1 | ||
| kind: Issuer | ||
| metadata: | ||
| name: webhook-issuer | ||
| namespace: linkerd-jaeger | ||
| name: linkerd-webhook-issuer | ||
| namespace: linkerd | ||
| spec: | ||
| ca: | ||
| secretName: webhook-issuer-tls | ||
| secretName: linkerd-trust-anchor | ||
| EOF | ||
| ``` |
There was a problem hiding this comment.
Huh. I've actually been advising people not to use the trust anchor as the root of trust for the webhooks?? They're very different security domains. Have I been contradicting y'all the whole time? 😂
There was a problem hiding this comment.
haha, this is a good question. Overall I think your recommendation is the better one and one that better aligns with proper security practices, even if we're just talking about east-west traffic. My reasoning is really more along the lines of "if someone is already so far in your system that they have access to your private trust anchor keys, you've got bigger problems than two issuers using a single trust anchor", but I do think for security best practices and credibility your position makes more sense. I'll update :)
Updated automatic cert-manager rotation docs to walk users through process of using cert-manager from start to end. With the new docs we eliminate the need to generate and maintain roots manually with
stepand instead create the entire cert chain with cert-manager. We also introduce using trust-manager to create acaBundleand allow linkerd to authenticate the cert-manager certificates without needing to maintain and pass in the ca file manually at install time.This change would make the same updates to both identity certificates and webhook certificates.