You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two scenarios here, as I understand. But what is the difference between them? In Case 1, we have Secret. But in Case 2, it is recommended to copy that secret into a seperate one? Why? We already have one?
Say you have a cert-manager Issuer which has the root certificate you want to trust in ca.crt. It's tempting to use the Secret directly and point at ca.crt, but a best practice would be to copy that root into a separate ConfigMap (or Secret).
What is the step here? It seems vague to me.
It's very strange in the Kubernetes world to suggest intentionally adding a step which seems to make automating infrastructure harder, but in the case of TLS trust stores it can be a wise choice.
The text was updated successfully, but these errors were encountered:
earik87
changed the title
Not clear what is said in the paragraph - cert-manager integration.
Confusing paragraph - cert-manager integration.
Mar 2, 2023
The step is to copy the CA certificate into a separate Secret, not consume it directly from the Secret where cert-manager wrote it to. The reason is so that when cert-manager updates the CA cert in the Certificate Secret, you can manually orchestrate rotation as is needed by your apps. Otherwise - if the CA cert was consumed directly from cert-manager's Secret - trust-manager would immediately overwrite all your trust bundle targets with the new CA certs, so your apps would no longer trust any certs signed by the old CA cert which may not be what you wanted.
Probably would be worth to write up a step-by-step rotation guide for a common use case (cc @SgtCoDFish )
Few issues related to this paragraph;
The text was updated successfully, but these errors were encountered: