kubewarden-controller
kubewarden-controller copied to clipboard
Feature Request: make cert-manager optional
Is your feature request related to a problem?
Currently Kubewarden installation required cert-manager to be installed. cert-manager is used to create the internal certifcate used to secure the communication between the Kubernetes API server and the dynamic admission controller hosted by the kubewarden-controller.
This webhook endpoint is used by the kubewarden-controller to perform validation of the CRD defined by Kubewarden.
Note well: each Policy Server service (one per PolicyServer CRD) has its own CA. In this case, the certificates are generated by the kubewarden controller itself.
Some users are not comfortable installing cert-manager on their clusters, hence they would like to make this an optional dependency.
Solution you'd like
This is a certificate used internally by Kubernetes. The service secured by it is not reachable outside of the cluster. Hence I think it doesn't make sense to have the user provide this certificate manually (like have this certificate signed by the user CA authority).
I think it would make sense to have the kubewarden-controller generate this certificate, maybe reusing the same code already in place to handle the Policy Server certificates.
Alternatives you've considered
No response
Anything else?
We have to ensure the certificate is properly rotated whenever it approaches its expiration.
An alternative, suggested by Anurag on k8s slack, is to use the certificate generation functions from Helm.
If I understand correctly, we could have helm generate a CA and then have helm generate a certificate signed by this CA. By doing that, we would be able to completely drop the cert-manager dependency.
This sounds cool, however I have two questions:
- How are we going to deal with the CA and the certificate expirations?
- What is going to happen to the CA and the certificate when
helm upgrade
is run? Are they going to be overwritten, renewed or left untouched?
Maybe Anurag knows it, I cannot mention him over here because I don't know his GitHub handle (I've pinged him on slack in the meantime)
-
genCA
function within helm generates a CA, and we can pass the validity of the certificate within the function as a parameter. Ref: https://helm.sh/docs/chart_template_guide/function_list/#genca -
The generation is happening on the client end, so every time you run
helm install
orhelm upgrade
orhelm template
, It's going to be overwritten.
Ok, let's make a try with that.
Keep in mind that, on top of generating the CA and the certificate, we must also update the [Validating|Mutating]WebhookConfiguration
created by helm (see here).
Right now the caBundle
field is automatically populated by cert-manager. We must ensure this is instead populated by helm with the contents of the CA that it just generated.