Revisit opt-out design for crd validator webhook

[exdx]

The crd validation webhook as currently implemented runs by default for every CRD that is associated with a BundleDeployment. There is a mechanism to opt-out of validation, based on applying an annotation to the CRD manifest itself, but essentially the webhook validation is opt-out. Based on the lack of upstream interest in the validation webhook, and the desire to keep rukpak small in scope and unopinionated where possible, it may make more sense to have the validation webhook be run on an opt-in basis (for users interested in the additional safety guarantees) versus always.

Furthermore, the current design of the opt-out setting (via the annotation) may not be the most ergonomic: bundle authors and bundle users are generally different parties. It may make more sense to make the validation toggle on the BundleDeployment associated with the CRD, so users of rukpak can make decisions at runtime on whether or not validation should run.

[exdx]

More context: upstream is moving away from validating webhooks generally (since they only have a few seconds to respond) and maybe this code should live in the controller logic.

Furthermore, rukpak wants to be more hands-off and less opinionated than OLM with respect to what's being installed.

The validator may be useful independently as its own Bundle that can be installed, versus installed by rukpak by default.

May also be implemented as a label on a separate object that the webhook responds to.

[exdx]

Another solution: move the validator webhook into a separate repository and apply it in a BD at rukpak install time.

[exdx]

Long term solution: have an API that sits in front of validation.

[exdx]

Moving to the next milestone so we can triage again.

[awgreene]

Two options emerged during Issue Triage:

1. The validatingWebhookConfiguration could be updated to only intercept CRDs with a specific annotation. This would require the ability to: -- Enable/Disable the validatingWebhookConfiguration -- Supply the annotation used to opt into CRD validation, allowing CRDs installed by RukPak to be validated while allowing users to apply CRDs without being intercepted.

2. The validatingWebhookConfiguration could be separated into its own bundle installed via RukPak. This would provide users with the means to opt in / out of the webhook.

@tylerslaton could you investigate and comment on the two approaches? I think it's important to note that:

• Pursuing option 1 does not prevent us from eventually pursuing option 2.
• If the validatingWebhookConfiguration is available when RukPak hits v1.0.0 it cannot be removed until the next major release.

[tylerslaton]

We've gone ahead and opened a new discussion thread to talk about the future of this component. We can decide what to do with this issue once we've reached a conclusion there.

https://github.com/operator-framework/rukpak/discussions/589

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.