Add option to disable webhook in Helm chart

[quentin-besse-orange]

Hello,

Is your feature request related to a problem? Please describe.
Currently, in Helm we don’t have the possibility to completely disable the webhook.
It seems that this option is missing.

Describe the solution you'd like

Add a parameter in values.yaml:

webhook:
    enabled: true

Advantages

• Provides more flexibility for users who don’t need the webhook.
• Simplifies deployment in environments where webhooks are restricted or not allowed.

/kind feature

[erikgb]

@quentin-besse-orange, the long-term goal is to remove the (validating) webhook completely. But right now, it serves an important role in validating trust-manager resources. How do you expect trust-manager to work without important validation enabled? It is currently an integral part of trust-manager and can/should not be disabled.

[quentin-besse-orange]

By disabling the webhook:

• There is no resource validation step
• The Trust Manager pod starts without any issues

What do you plan to use instead of the webhooks ?

[erikgb]

What do you plan to use instead of the webhooks ?

CEL expressions in CRDs: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules. We are already working on a migration from Bundle to ClusterBundle, which would also make the API more "self-validating".

There is no resource validation step

This would not be acceptable, as it would require the controller to have a lot more advanced error-handling. Admission control is important for controllers.

[quentin-besse-orange]

Do you have a roadmap available? I’d be happy to contribute.

[quentin-besse-orange]

I wonder if the goal is to replace all webhooks with CEL.
If so, I don’t see how some cases could be handled. Currently, the validations require comparing:

type BundleSpec struct {
	Sources []BundleSource `json:"sources"`
	Target  BundleTarget  `json:"target,omitempty"`
}

based on their name, in order to check:

• “cannot define the same ConfigMap as both source and target”
• “cannot define the same Secret as both source and target”

I’d be interested to see how this could be achieved using CEL alone.

Otherwise, if we keep webhooks in addition to CEL: is it possible to enable them conditionally, similar to how Crossplane does?

[erikgb]

If you look at the new API (non-user-facing at present), ClusterBundle, you can see some examples on how to fix these validations using CEL. Label selector validations are currently impossible to validate with CEL, but K8s is working to fix this upstream.

Otherwise, if we keep webhooks in addition to CEL: is it possible to enable them conditionally, similar to how Crossplane does?

We would have to come back to this question. As long as the core validations are handled by CEL, and only "usability" validations remain implemented as webhooks, we can consider it.

[quentin-besse-orange]

I wasn’t able to find any validation logic preventing a source from being identical to the target (same ConfigMap/Secret).
My understanding is that this would fall under the ‘usability’ validations category rather than core validations handled by CEL.

Could you please confirm if my understanding is correct?

By the way, thanks for your response.

[erikgb]

I wasn’t able to find any validation logic preventing a source from being identical to the target (same ConfigMap/Secret).

That is correct. This particular validation hasn't been ported over to ClusterBundle. We need to delve into the history to figure out why exactly this validation was added in the first place. To me, this validation makes less sense, as another Bundle may have overlapping sources/targets.