-
Notifications
You must be signed in to change notification settings - Fork 693
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.
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
Update webhook for kubebuilder v2 #1769
Comments
Want to discuss options for deployment. Previously, at runtime the operator would deploy the webhook configuration and generate the required certs. Kubebuilder v2 does not do this. See here: https://kubebuilder.io/cronjob-tutorial/running-webhook.html Options1. Hard dependency on cert-managerThis is the recommended path from kubebuilder. In this case, we would
I think we also need to provide the current, webhookless yaml. Some people may think it is too much trouble to install for too little benefit. We already have two, so this means we produce four (potentially three if we decide to tell people they need to be on k8s 1.13+ for webhooks). Pros
Cons
2. Re-implement the webhook installerWe could re-implement the removed kubebuilder functionality that automatically installs the webhook and generates certificates. Pros
Cons
3. Do not implement webhook validationWe could decide that webhooks do not provide enough value to be worth the trouble.
RecommendationOption 1. We provide all-in-one yamls that include webhooks and cert-manager certificates. We continue to provide the existing yaml. We also update the documentation to explain
We may also want to provide instructions / a make target for generating your own CA and certificate. I'm not sold on that yet. I think re-implementing the webhook auto-installer is a bit hacky. Cert-manager is already much more tested for managing certificates. We would likely not do as good of a job, but it would still take up a lot of our time. If we do decide to implement it, it might be helpful to maintain it as a separate package so other operators can use it easily. I would not be in favor of option 2. It seems like a lot of effort for not much reward. I think the validations we provide in the webhook are useful enough to be worth the effort of maintaining and deploying them, so would not be in favor of option 3. What do you all think? |
That's a great summary @anyasabo 👍 I think I would still be in favour of option 2 though (implementing stuff ourselves). My arguments:
Can we ship the webhook configuration as yaml in our operator manifest? So the operator itself does not need to create/update the webhook config, and that resource will be deleted if the user uninstall the operator through its manifest. The only responsibility of the operator would be to create/update the certificates secret. |
I can only second what @sebgl said: great summary of the options we have. I think we kind of want to do both?
|
I was thinking that since the webhooks are more of a "nice to have" feature that wide compatibility is not as necessary. Also, the actual configuration of the certificates to utilize cert-manager is not complex, see the example here. So changing it for a specific version should not be too challenging.
They would likely have a similar problem with the validating webhook configuration but I take your point.
This is clever, I'm for it. There will be a disruption while the operator bootstraps itself but since it only applies to Elastic resources that seems acceptable. Note that as Peter mentioned we would need to ship an empty secret (that it later fills in with its certificate), and the operator would need permissions to update the webhook configuration since it contains the CA. I'm good with the plan as described by @pebrc . Unless there's different suggestions I may try to merge in the validation refactor first since it is a pain to keep up to date, then merge in the automatic webhook cert generation later on. |
Unassigning myself since I will be out for a while. I think an intermediate step might before working on the automatic certificate creation might be to migrate the operator to a deployment from kubebuilder v2 instead of an sset. That way we can take advantage of the kubebuilder kustomize examples rather than needing to roll our own, and we already talked about wanting to do it anyway. We might end up wanting to provide webhook and non-webhook yamls since in the past they caused issues for people with restrictive networks, and kustomize would help make that easier. Definitely not a requirement but just something I was considering. |
Documentation has been added in #2158. |
Parent issue #1188
As part of moving to kubebuilder v2 in #1723, the validating webhook was removed. Kubebuilder v2 changes how webhooks are built and deployed. We should update the webhook to work with kubebuilder v2.
Removing the webhook validation also disabled the validation in the trial license in
pkg/controller/license/trial/trial_controller.go
, which should also be re-enabled as part of this issue or have a new issue created for it.The text was updated successfully, but these errors were encountered: