[RFE] Allow Cert-Manager or Service CA Operator to manage CA Certs

[awgreene]

Feature Request

Source Generated via a OLM WG discussion with @cdjohnson.

Is your feature request related to a problem? Please describe. OLM currently handles CA Cert generation and rotation using self-signed certs. Many customers desire the ability to "bring their own certs" to better adhere to existing policies.

Describe the solution you'd like Many admins already use established tool such as Cert-Manager or the Service CA Operator to implement company-wide certificate policies on clusters. OLM's existing Cert generation is largely rudimentary and could benefit greatly from outsourcing this work to established solutions.

[Jamstah]

Minutes from working group dev meeting: https://docs.google.com/document/d/1Zuv-BoNFSwj10_zXPfaS9LWUQUCak2c8l48d0-AhpBw/edit#

Chris: Understand the OLM Webhook integration and how certs are issues without cert-manager I think it works like this: OLM generates a 2-year self signed CA cert for itself. Alex: Yep For each WebHook that’s installed, it generates a CA-Signed cert for the webhook server and serves that. Alex: This is partially correct - OLM generates a Self Signed CA Cert for each deployment that includes a webhook. If multiple webhooks exist on a deployment, then all webhooks in the deployment use the same CA. In the MutatingWebookConfiguration, it adds the CA cert to the CA Bundle, and that’s how Kube authenticates the webhook endpoint. Alex: Applies to validatingWebhookConfigurations and ConversionWebhook definitions in CRDs as well.

How does rotation work? OLM performs periodic checks against the CSV timestamp https://github.com/operator-framework/operator-lifecycle-manager/blob/836d8441209501c4ee2b8a2dc4be3374bf3b9ea4/pkg/controller/operators/olm/operator.go#L1567 https://github.com/operator-framework/operator-lifecycle-manager/blob/836d8441209501c4ee2b8a2dc4be3374bf3b9ea4/pkg/controller/install/certresources.go#L210

Can cert-manager be used instead of self-signed? The kubebuilder docs of course talk about cert-manager, so a lot of folks get confused. Alex: We have discussed moving Cert manager but haven’t committed to doing so yet. Action: Add more details here? Delegate Cert Generation/Rotation RFE

Evan: Can we discuss why self-signed certs are not sufficient Chris: Customers are demanding “Bring your own Cert” want a CA to be bound to a namespace or workload instance which allows you to do endpoint based authentication The industry in general is moving more towards zero trust CAs Outsourcing this to an outside service that provides policy based scoped reduces this work “All TLS certs are signed with the corporate CA” The more we get into these very large customers around compliance and governance is Cert administrator, DBA, Docker Admin, etc.. Arbitrary rules Lots of knobs required to satisfy requirements Joe Lanford: Which version of TLS also pops up, Crypto apis, etc… Joe Huizenga: Kubebuilder based project generates different outputs than required by the CSV. Allowing users to choose their cert manager system makes it much easier for cluster administration.

Evan: Lots of benefits associated with moving this out OLM implementation is very naive, no cross signing, no revocation, other solutions have this stuff sorted already so why not use them?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[camilamacedo86]

I just would like to highlight that by default kubebuilder projects are scaffold with cert-manager. So, its users also are unable to publish the operator without removing it.

[wallrj]

A quick note to say that I'm currently creating cert-manager bundles for https://github.com/operator-framework/community-operators/pull/4103 and https://github.com/operator-framework/community-operators/pull/4128 which have been merged already (maybe a bit prematurely).

I'm considering whether to disable the cainjector component, since it's not used by cert-manager's own webhooks when installed via OLM. But cainjector is used by Kubebuilder controllers, to install the webhook serving and CA certs, so perhaps I should keep it enabled.

• https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/golang/v2/scaffolds/internal/templates/config/kdefault/enablecainection_patch.go

[ricardozanini]

Hi! To add me as a watcher in this issue and bring light to another use case.

I'm preparing a Knative Eventing Source to OLM, but at this time, I won't be able to ship it with the Admission Webhooks because OLM and Knative platform both have CA management. So it would be nice if OLM could let the webhooks be managed by the operator architecture instead. I understand that this issue is quite close to what I need.

For example, on Knative, the certs are managed by the platform, and it's part of the update/installation process to make sure that all admission webhooks are reconciled. Therefore, to integrate with OLM, it would require some work on the Knative side to be aware of the certs managed by OLM.

[svghadi]

Hi, any updates on this RFE? I have a use-case where I want to use Service CA operator to manage webhook certs.