Description
In what area(s)?
/area sentry
Describe the proposal
Help the operators read
This proposal is based on my production experience running Dapr (v1.13) via its Helm chart on a custom k8s cluster. The documentation says (at the very top), you can bring your own certificates, but you might as well use the default ones.
Dapr allows operators and developers to bring in their own certificates, or instead let Dapr automatically create and persist self-signed root and issuer certificates.
Not loving to read all the letters of a documentation for a feature you don't care for, you might as well stop reading right there. The sentence doesn't say you shouldn't let Dapr handle this for you unless you opt for a lovely cluster disaster one year later. Well, it does, but so subtly, one might tend to think of this being later handled somehow more gracefully (than ending up with the dapr-operator perpetually killing the dapr-enabled pods, for which the dapr-injector failed to inject the sidecar, because it saw an expired certificate in dapr-sentry 😮💨).
If custom certificates have not been provided, Dapr automatically creates and persist self-signed certs valid for one year.
The warning about your inevitable downtime - if you use the default configuration - is much farther in the docs.
Avoiding downtime when rotating certificates
To avoid downtime when rotating expiring certificates your new certificates must be signed with the same private root key as the previous certificates. This is not currently possible using self-signed certificates generated by Dapr.
Correcting this by warning readers in the very 1st section should be pretty easy and it's my first mini-proposal.
Make their life easier
Naturally, no one wants a production outage, so if there's a way, and it seems there is one pretty close, we should leverage it. When Dapr doesn't offer automatic root cert rotation, as a diligent operator you (finally) choose the other option - providing your own keys&certs. Because we all know that's a manual chore, we use the lovely cert-manager k8s operator (greetings JoshVanL), which automatically creates and rotates TLS Secrets (which have these deliberatley unmodifiable keys ca.crt, tls.key and tls.crt). There you end up with a secret that's by default almost the same as the sentry's dapr-trust-bundle (with its keys ca.crt, issuer.key and issuer.crt). The only way to pass these values to the secret is via Helm chart values, unnecessarily dragging them out of the Secret already in k8s and passing them to Helm values.
I'd like to be able to skip this step and be able to set the name of the existing secret in helm values, in which case the dapr-trust-bundle wouldn't be managed by helm (or sentry) at all, but mounted the usual way to the sentry pod. The sentry values.yaml section could look like this:
tls:
existingSecret:
name: my-trust-bundle
caCert: ca.crt
issuerKey: tls.key
issuerCert: tls.crtI see there's been some fairly recent movement on the TLS front, fixing some original design inconsistencies for v1.14 and improving the default rotation seems to be also in the works, however I don't see this particular use-case is being tackled yet.