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

Dangerous MutatingWebhook for all "pod" resources that cannot be disabled in Helm values #90

Open
vpedosyuk opened this issue Feb 7, 2024 · 3 comments

Comments

@vpedosyuk
Copy link

vpedosyuk commented Feb 7, 2024

I'm talking mainly about this part of Helm templates:

- admissionReviewVersions:
- v1
- v1beta1
clientConfig:
service:
name: kruise-webhook-service
namespace: kruise-system
path: /mutate-pod
failurePolicy: Fail
name: mpod.kb.io
namespaceSelector:
matchExpressions:
- key: control-plane
operator: NotIn
values:
- openkruise
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
sideEffects: None

It creates a webhook for any "CREATE" operation of the "pod" resource - this basically affects everything in a Kubernetes cluster. There can be various reasons for OpenKruise controller to be unavailable, thus, it might be very useful to have an option to make the webhook isolated only to resources in "*.kruise.io" API group.

Here's an easy example when I scaled "manager" to 0 replicas and trying to create a dummy pod:

$ kubectl run busybox --image=busybox
Error from server (InternalError): Internal error occurred: failed calling webhook "mpod.kb.io": failed to call webhook: Post "https://kruise-webhook-service.kruise-system.svc:443/mutate-pod?timeout=10s": no endpoints available for service "kruise-webhook-service"
@furykerry
Copy link
Member

many openkruise features rely on the pod creation webhook ,such as sidecarset and workloadspread, if you does not rely on such features, you can disable the webhook by turning off the PodWebhook feature gates in the helm chart .

@vpedosyuk
Copy link
Author

@furykerry yes, I can set featureGates: PodWebhook=false in the Helm chart but, unfortunately, it applies only to the Kruise controller application itself (through env vars) and it doesn't directly apply to the MutatingWebhookConfiguration and ValidatingWebhookConfiguration Kubernetes resources.

So I made a PR to fix that (and some other issues): #91

@furykerry
Copy link
Member

@vpedosyuk thanks for your contribution, most change of your patch are included in the 1.6.0 chart along with other feature release:
https://github.com/openkruise/charts/pull/95/files#diff-0c128c764f13a0883f1f188d84b75bdd0e4112d272d4e40efd84a54f5af56a43

The one change is missing however, that is the one to change failpolicy of pod-webhook, we think the webhook function is crucial for the feature that rely on webhook e.g. sidecarset, simply skipping the webhook can make kruise working incorrect which may introduce unexpected problem to the cluster. A more complete solution is required which may involve mark the pod that is actually managed by kruise with label, so we can leave the issue open for future implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants