Confusing paragraph - cert-manager integration.

[earik87]

Few issues related to this paragraph;

1. 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).

2. 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.

[irbekrm]

What is the step here? It seems vague to me.

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 )

[hawksight]

@wallrj - just flagging this issue as potenitally solvable or partially solved via a good tutorial on CAs in cluster etc.