Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated Automatically Rotating Certs Docs #1757

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

deusxanima
Copy link

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 step and instead create the entire cert chain with cert-manager. We also introduce using trust-manager to create a caBundle and 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.

…ocess of using cert-manager for entire trust chain

Signed-off-by: Alen Haric <[email protected]>
Copy link
Member

@kflynn kflynn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have questions, though not about the quality of the writing. 😂

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"to create"

commonName: root.linkerd.cluster.local
isCA: true
duration: 87600h0m0s
renewBefore: 87264h0m0s
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. I had thought this was "renew, at latest, when this many hours are remaining"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're correct. updating to clarify.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as above re renewBefore, but also, duration should be 48 hours, correct?

Comment on lines +31 to 35
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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we refer to the main doc above rather than duplicating the basic setup twice?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +143 to 159
## 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
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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? 😂

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants