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

Mutating webhook should support setting Allowed: false #189

Open
SOF3 opened this issue Jun 9, 2022 · 0 comments
Open

Mutating webhook should support setting Allowed: false #189

SOF3 opened this issue Jun 9, 2022 · 0 comments

Comments

@SOF3
Copy link

SOF3 commented Jun 9, 2022

Currently, slok/kubewebhook only supports StopChain and MutatedObject, or returning 500 ISE directly, but it does not support rejecting the request directly in the validating webhook style.

type MutatorResult struct {
// StopChain will stop the chain of validators in case there is a chain set.
StopChain bool
// MutatedObject is the object that has been mutated. If is nil, it will be used the one
// received by the Mutator.
MutatedObject metav1.Object
// Warnings are special messages that can be set to warn the user (e.g deprecation messages, almost invalid resources...).
Warnings []string
}

I have confirmed that returning {response: {allowed: false}} in mutating webhooks has a similar effect as validating webhooks.

As explained in #188, kube-apiserver handles the response differently if webhook server responds with 200 or with 500. In particular, in my use case, I am adding alerts for the apiserver_admission_webhook_rejection_count metric with error_type=calling_webhook_error, which cannot distinguish upstream-side 500 errors from proxy-side 502 errors. Allowing returning allowed: false in the mutating webhook allows me to collect the correct metrics.

SOF3 added a commit to SOF3/kubewebhook that referenced this issue Jun 9, 2022
SOF3 added a commit to SOF3/kubewebhook that referenced this issue Jun 9, 2022
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

1 participant