Allow removing Bundles whilst keeping the synced CA certs

[irbekrm]

At the moment, each target configmap has an owner reference to the Bundle for which it was created.
This means that if a Bundle gets deleted, the configmaps will be deleted by Kubernetes garbage collector.

This can be useful for folks who sync them to a large number of namespaces and want to be able to easily delete Bundle and all related configmaps.

Judging from our experience with cert-manager, it is likely that in the future there will be scenarios where users end up uninstall and re-install trust manager including the Bundle CRD, either to perform a more complex upgrade or to perform some other cluster component configuration change like moving to a different deployment mechanism etc.

If configmaps with CA certs get deleted it means that

• new pods that mount these configmaps cannot start
• any service that reads the CA certs from configmaps directly can't perform its operations.
  This would mean that it is not safe to re-install trust-manager as it can cause downtime.

I think we should make it possible to re-install trust-manager without deleting the synced CA certs whilst still giving users an easy way to delete Bundles and associated configmaps.

We could:

• make owner references optional and configurable via flag
• make owner references optional and configurable on each Bundle CR
• remove owner references altogether, provide a cmctl command to clean up configmaps for Bundles (depends on splitting cmctl out of cert-manager codebase)

At the moment owner references are used heavily by trust controller (to filter configmaps to watch, list etc). If we are going to get rid of them or make them optional, we'd need to devise another way how to filter target configmaps. One way could be labelling. Server side apply could also help- we could look at managed fields to determine whether a configmap was added by trust manager #89 . Also, if we are going to do it, it'd be easier now than when there are more users and stability guarantees.

The next step for this issue would be to come up with a design.

[cert-manager-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale

[erikgb]

/remove-lifecycle stale

[cert-manager-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale

[erikgb]

/remove-lifecycle stale