patch validatingwebhookconfigurations
An existing ValidatingWebhookConfiguration already carries the rules, namespaceSelectors and CA trust that a new one would have to earn.
Redirecting its endpoint turns it into a passive copy of every matching admitted object, while widening failurePolicy or narrowing rules disables the policy engine behind it instead.
Both are quieter than creating or deleting the object.
- API Group
- admissionregistration.k8s.io
- Scope
- cluster
- Audit Level
- RequestResponse
Escalation Paths
Create a ValidatingWebhookConfiguration whose rules match the kinds you want to read, or patch an existing one to point at your endpoint and inherit its rules and CA trust.
Validating webhooks receive the full object, so Secret and ConfigMap contents leave the cluster on every admission.
The configuration write and each triggering request are both recorded in the audit log.
What no Kubernetes log holds is the payload sent outbound, so the copy itself leaves no cluster-side record.
failurePolicy Ignore keeps admission working when the endpoint is unreachable, which is what makes it quiet.
Additional rights needed:
Delete the ValidatingWebhookConfiguration or MutatingWebhookConfiguration objects that back a policy engine, or patch one to widen failurePolicy or narrow its rules.
Third-party enforcement such as Gatekeeper, Kyverno, or image signature verification stops rejecting anything.
Pod Security Admission is unaffected.
It is a built-in API server controller rather than a webhook, so namespace enforce labels still apply.
On its own this only removes a guard.
It becomes privilege only alongside a verb that creates the workload the webhook was rejecting.
Additional rights needed: