search

cert-manager / trust-manager

trust-manager is an operator for distributing trust bundles across a Kubernetes cluster.
https://cert-manager.io/docs/projects/trust-manager/
Apache License 2.0
251 stars 66 forks source link

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

Open anael-l opened 2 months ago

anael-l commented 2 months ago

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 https://github.com/cert-manager/trust-manager/pull/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 commented 2 months ago

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 commented 2 months ago

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.