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
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.
// StopChain will stop the chain of validators in case there is a chain set.
StopChainbool
// 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.
The text was updated successfully, but these errors were encountered:
SOF3
added a commit
to SOF3/kubewebhook
that referenced
this issue
Jun 9, 2022
Currently, slok/kubewebhook only supports
StopChain
andMutatedObject
, or returning 500 ISE directly, but it does not support rejecting the request directly in the validating webhook style.kubewebhook/pkg/webhook/mutating/mutator.go
Lines 14 to 22 in 7cda665
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 witherror_type=calling_webhook_error
, which cannot distinguish upstream-side 500 errors from proxy-side 502 errors. Allowing returningallowed: false
in the mutating webhook allows me to collect the correct metrics.The text was updated successfully, but these errors were encountered: