Starting from kubernetes 1.26, CEL support has been added into Kubernetes. On top of ValidatingAdmissionPolicy the ValidatingWebhookConfiguration and the MutatingWebhookConfiguration CRDs obtained a new field: matchConditions.
The matchConditions field allows to specify a list of CEL expressions that are used to determine whether the webhook endpoint should be called or not.
This is extremely powerful, since it allows to do something like "do not call this webhook endpoint if !object.spec.containers[0].image.startsWith("registry.local.lan").
The AdmissionPolicy and the ClusterAdmissionPolicy CRDs should be updated to feature a matchConditions field.
The kubewarden-controller should then propagate them into the (Validating|Mutating)WebhookConfiguration) objects.
Alternatives you've considered
No response
Anything else?
The matchConditions field has been introduced starting with Kubernetes 1.27 (see here).
Currently (Jun 2024), Kubernetes 1.26 has been EOL for ~ 3 months. That means all the maintained Kubernetes versions have this feature available behind a feature gate:
Note: Use of matchConditions requires the featuregateAdmissionWebhookMatchConditions to be explicitly enabled on the kube-apiserver before this feature can be used.
Starting from Kubernetes 1.30 the feature gate is gone, since this feature graduated to stable.
I think our CRDs should always have the matchConditions field. We have to figure out what the controller should do when running on Kubernetes >= 1.27 < 1.30 and the AdmissionWebhookMatchConditions feature gate is disabled.
I suspect in this condition the (Validating|Mutating)WebhookConfiguration resources would still have this field, but it would not have any effect. I hope that's the case, because it would allow our controller to always propagate the matchConditions field, without having to perform any kind of check.
I would not consider the use case of propagating matchConditions on a Kubernetes cluster <= 1.26 since they are all EOL. We can update our docs/helm charts to require Kubernetes >= 1.27
Is your feature request related to a problem?
Starting from kubernetes 1.26, CEL support has been added into Kubernetes. On top of
ValidatingAdmissionPolicytheValidatingWebhookConfigurationand theMutatingWebhookConfigurationCRDs obtained a new field:matchConditions.The
matchConditionsfield allows to specify a list of CEL expressions that are used to determine whether the webhook endpoint should be called or not.This is extremely powerful, since it allows to do something like "do not call this webhook endpoint if
!object.spec.containers[0].image.startsWith("registry.local.lan").More information can be found here.
Solution you'd like
The
AdmissionPolicyand theClusterAdmissionPolicyCRDs should be updated to feature amatchConditionsfield.The kubewarden-controller should then propagate them into the
(Validating|Mutating)WebhookConfiguration)objects.Alternatives you've considered
No response
Anything else?
The
matchConditionsfield has been introduced starting with Kubernetes 1.27 (see here).Currently (Jun 2024), Kubernetes 1.26 has been EOL for ~ 3 months. That means all the maintained Kubernetes versions have this feature available behind a feature gate:
Starting from Kubernetes 1.30 the feature gate is gone, since this feature graduated to stable.
I think our CRDs should always have the
matchConditionsfield. We have to figure out what the controller should do when running on Kubernetes >= 1.27 < 1.30 and theAdmissionWebhookMatchConditionsfeature gate is disabled.I suspect in this condition the
(Validating|Mutating)WebhookConfigurationresources would still have this field, but it would not have any effect. I hope that's the case, because it would allow our controller to always propagate thematchConditionsfield, without having to perform any kind of check.I would not consider the use case of propagating
matchConditionson a Kubernetes cluster <= 1.26 since they are all EOL. We can update our docs/helm charts to require Kubernetes >= 1.27