cert-manager should not be a hard requirement

[benmoss]

Is your feature request related to a problem? Please describe.
As an operator I'd prefer not to have to install cert-manager if I'm not trying to do anything fancy with certificate management.

Describe the solution you'd like
A documented way for users to bring their own certificates, but not necessarily via cert-manager.

Additional context
Strimzi is a comparable operator for managing Kafka clusters. They do not have a dependency on cert-manager and this is their documentation for how to manage your own certificates.

It seems like it automatically can provision its own certificates, but in the case of bring-your-own it just expects the user to provide Kubernetes secrets containing the certificates and keys. A user could use cert-manager to create these and still get the benefits of cert-manager, or whatever certificate management system they want.

[ChunyiLyu]

Hi @benmoss, I'm going to convert this issue to a github discussion because it seems to be more of a question 😄

[ChunyiLyu]

Hi @benmoss, we have release manifest that does not depend on cert-manager. In our release artifact, the manifest with name suffix -certmanager.yaml is for people with cert-manager, the other one with name messaging-topology-operator.yaml is for people with generated cert themselves: https://github.com/rabbitmq/messaging-topology-operator/releases

In our installation docs, we have a dedicated section about generated certs use case in Install with Generated Certificates. This installation doc is linked in the repo README. I love to learn from you about your feedback to these docs and any suggestions on how to make them more visible.

[benmoss]

I don't want to bring my own certificates or install cert-manager. I just want the operator to generate certificates for me.

[vrabbi]

i agree that having the operator manage cert generation itself would be great. the issue with cert manager is that many different products are now depending on it and as is well known cert manager like to bump API versions often. this has caused issues of creating a very complex matrix of what version i need for each of my tools and i have bumped into cases where i needed a specific version for tool A but tool B wouldnt work with that version of Cert Manager.
having a Self Signed option + a BYO Cert + a Cert Manager option would be the best UX in my opinion

[gvmw]

I can see the value of this too, especially when we start dealing with different components depending on cert-manager, and cert-manager versions becoming an issue. I don't think we are far off hitting this problem, but I am not aware of this being a problem today.

I would keep this in its current state for 5 more weeks, and come back to it after eventing-rabbitmq becomes stable.

[vrabbi]

It has become even more relevant since 1.6 was released of cert manager which removed a bunch of long time deprecated APIs that are still in use by many tools unfortunately