You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ECK allows restricting its responsibilities to a set of namespaces or even a single namespace. The ValidatingAdmissionWebhook we deploy is unaware of this restriction. That means in environments where multiple instances of ECK are running all instances will validate all requests in parallel. If the user is running different (minor) versions of ECK at the same time (e.g. during an upgrade process of the operator fleet) they might come to different conclusions as to what is admissible.
There is currently no mechanism in Kubernetes to restrict a webhook to just a subset of resources in a way that is useful for ECK:
namespaceSelector allows limiting the namespaces a webhook is responsible for which sounds like what we would want. But it requires the namespaces to be annotated with labels, which would require additional permissions in the operator process
objectSelector allows limiting the objects to be validated using labels on the resources themselves, we could introduce an additional operator identifier label and restrict the webhook based on that.
A third option that comes to mind is just implementing the restriction in the webhook itself: as we cannot easily prevent all webhooks from being called we could short-circuit that call in all those webhooks belonging to ECK instances that are not responsible for the namespace in question.
The text was updated successfully, but these errors were encountered:
ECK allows restricting its responsibilities to a set of namespaces or even a single namespace. The ValidatingAdmissionWebhook we deploy is unaware of this restriction. That means in environments where multiple instances of ECK are running all instances will validate all requests in parallel. If the user is running different (minor) versions of ECK at the same time (e.g. during an upgrade process of the operator fleet) they might come to different conclusions as to what is admissible.
There is currently no mechanism in Kubernetes to restrict a webhook to just a subset of resources in a way that is useful for ECK:
namespaceSelector
allows limiting the namespaces a webhook is responsible for which sounds like what we would want. But it requires the namespaces to be annotated with labels, which would require additional permissions in the operator processobjectSelector
allows limiting the objects to be validated using labels on the resources themselves, we could introduce an additional operator identifier label and restrict the webhook based on that.A third option that comes to mind is just implementing the restriction in the webhook itself: as we cannot easily prevent all webhooks from being called we could short-circuit that call in all those webhooks belonging to ECK instances that are not responsible for the namespace in question.
The text was updated successfully, but these errors were encountered: