Support other ways to generate service TLS certificate in the Helm chart

[anael-l]

Hi,
This project is exactly what I need for managing internal CAs in Openshift clusters.

I don’t use cert-manager, and ideally, I would like to be able to install trust-manager without it.
As of #157 , I see this has been addressed, but the doc advises against using this in production.

One of Openshift’s operator allows for generating service certificates in a secret by annotating a secret, signed by the cluster’s CA:
https://docs.openshift.com/container-platform/4.15/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate
It also can inject a CA bundle into the webhook: https://docs.openshift.com/container-platform/4.15/security/certificates/service-serving-certificate.html#add-service-certificate-validating-webhook_service-serving-certificate

Right now, the Helm chart only allows to either use the Helm generated certificate, or the cert-manager one.
Would you be willing to have another option to use the Openshift managed certificates?

I can understand that it’s not wanted to have a solution that is specific to a platform. In that case, would you consider having an option to not manage the certificate in the Chart, and let the user configure it another way?
I could then add the needed annotations the service and webhook.

Thanks

[erikgb]

I prefer avoiding a solution tailored for OpenShift, even if we also run OpenShift in our target clusters. But a more generic extension mechanism for webhook certs seems like a valid ask. @anael-l, do you know if OpenShift supports injecting CA certs into CRDs for conversion webhooks? Yes, it does, ref. https://docs.openshift.com/container-platform/4.15/security/certificates/service-serving-certificate.html#add-service-certificate-crd_service-serving-certificate. We will probably add new API versions that will require conversion webhooks.

To use the OpenShift mechanism to do this with the current webhook (validating), I think two things are needed:

1. Bring your own secret for the webhook server certificate.
2. Add arbitrary annotations to webhook configuration resources.

[anael-l]

I've never used it, but this seems to be what you are looking for: https://docs.openshift.com/container-platform/4.15/security/certificates/service-serving-certificate.html#add-service-certificate-crd_service-serving-certificate

1. For the secret, I think it is already possible to do, as the Deployment mounts a secret named {{ include "trust-manager.name" . }}-tls.
   Maybe we could add a variable to specify another secret name.
   That could be tied to a condition that would not create a secret with Helm nor a Certificate with cert-manager.

2. In the Openshift case, we would need to specify a different annotation for the Service:
   service.beta.openshift.io/serving-cert-secret-name: {{ include "trust-manager.name" . }}-tls
   and the ValidatingWebhookConfiguration:
   service.beta.openshift.io/inject-cabundle: "true"

Now that I see it, the annotation for the service has to be templated for the secret name.
As it will be defined in the values file, it will not really be feasible except if we use the tpl function when we apply the annotation in the service.
Maybe we can workaround this by setting a fix value for the secret name.

[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]

For anyone following this issue: I am currently working on a "webhook-cert-lib", that we also will use in cert-manager eventually - replacing the "dynamic authority" feature currently inside cert-manager to bootstrap and renew cert-manager webhook certificates. This will take some time to finish, but the process has started. Right now, I have a POC PR showing this is possible: #468.

Follow the cert-manager-dev channel on Slack and/or join put bi-weekly meetings to follow the progress on this. 😺