Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
anael-l opened this issue Aug 14, 2024 · 4 comments · May be fixed by #420
Open

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

anael-l opened this issue Aug 14, 2024 · 4 comments · May be fixed by #420
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@anael-l
Copy link

anael-l commented Aug 14, 2024

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
Copy link
Contributor

erikgb commented Aug 14, 2024 •
edited
Loading

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
Copy link
Author

anael-l commented Aug 14, 2024 •
edited
Loading

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.

@anael-l anael-l linked a pull request Aug 19, 2024 that will close this issue
Draft
@cert-manager-bot
Copy link
Contributor

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

@cert-manager-prow cert-manager-prow bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 12, 2024
@erikgb
Copy link
Contributor

erikgb commented Nov 23, 2024 •
edited
Loading

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(helm): Allow external TLS provider for webhook anael-l/trust-manager
3 participants
@erikgb @anael-l @cert-manager-bot