Certificate Deletion Policy for Finer Grained Control of Secret Cleanup about cert-manager

[onelapahead]

https://cert-manager.io/docs/usage/csi-driver/#why-use-csi-driver could be alternative for the use case of:

The same cert-manager installation is then used for dynamically provisioning mTLS Certificates for various internal microservices from an internal CA. Instances of the microservices may come and go, and so their Certificates are deleted as they are. But over time Secrets are then accumulating in Namespaces and require scripting / automating their cleanup to avoid etcd storage issues, affecting Secret watchers, etc. Enabling the CLI option for cert-manager could solve this, but then the Ingress Certificates would also be automatically cleaned up which is undesirable.

depending on the specifics.

Though, yet-another CSI driver on a cluster has a few extra downsides IMO:

1. Another DaemonSet means more processes and if you have to set resource requests / limits you might be eating memory / CPU reservation space on your machines (thought requests of 0 might be fine).
2. If you are a writing an operator that integrates with cert-manager, you added another component dependency on your operator users. Daemon components require extra scrutiny from enterprise platform and security teams, and might be a blocker for operator installation.

[maelvls]

Hey, thanks for opening this. @RomanenkoDenys and I tried adding the new field cleanupPolicy 2 years ago. There was enough maintainer buy-in (although not a complete consensus on the problem statement), but we weren't able to finish it. I think time was lacking.

What's interesting in your description is that you are bringing new use-cases that I hadn't written in the design I had started (#5324)

• One one side, it is important to keep Let's Encrypt secrets around just in case,
• But on the other side, as you pointed out, mTLS without csi-driver is painful due to the secrets piling up.

I think the next step for this new feature would be to write a design document. You can create a new PR and re-use any part you like from #5324 as a starting point. The question that the design should answer most importantly is "what's the problem".

The lack of a good problem statement is what made me struggle gain consensus among maintainers. The biggest question that this design needs to answer is: why would you not want to install cert-manager-csi-driver, or differently said: why csi-driver is a problem in some clusters? You said:

Another DaemonSet means more processes and if you have to set resource requests/limits you might be eating memory/CPU reservation space on your machines (thought requests of 0 might be fine).

Is that the reason you prefer not to install csi-driver? I'd like to understand this problem better, especially since csi-driver will most probably have a reasonable CPU request and low memory request/limit as it only watches certificate requests.

If you are a writing an operator that integrates with cert-manager, you added another component dependency on the users of your operator.

I'd like to know more; @SpectralHiss @hawksight have you also noticed that cert-manager csi-driver is a no-go for enterprise users?