Skip to content
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

Webhook ignores namespace restriction #3431

Closed
pebrc opened this issue Jul 14, 2020 · 0 comments · Fixed by #3876
Closed

Webhook ignores namespace restriction #3431

pebrc opened this issue Jul 14, 2020 · 0 comments · Fixed by #3876
Assignees
Labels
discuss We need to figure this out >enhancement Enhancement of existing functionality

Comments

@pebrc
Copy link
Collaborator

pebrc commented Jul 14, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss We need to figure this out >enhancement Enhancement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants