admission webhook denied the request: A validating admission webhook rejected the object
This means a policy webhook examined your object and refused it. The webhook's own reason follows the phrase, and that reason is the only thing that matters — Kubernetes is just relaying it.
Applies to: All Kubernetes versions with admission webhooks
What it means
Validating admission webhooks run after authentication and authorization and before an object is persisted. They can accept or reject anything, for any reason their author chose, and the API server relays the rejection verbatim: admission webhook "policy.example.com" denied the request: …. The important structural fact is that this is not a Kubernetes rule — it is a rule someone installed. Policy engines, service meshes, image signature verifiers, and cost or security tooling all install webhooks, so the first question is always which webhook produced the message, and the second is what policy it is enforcing.
Most common causes
- A policy engine rejecting the object for a rule such as a required label, a forbidden capability, or a disallowed registry.
- An image signature or provenance verifier rejecting an unsigned or unattested image.
- A resource policy requiring limits and requests to be set.
- A service mesh webhook rejecting a configuration it cannot inject into.
- A custom resource's own validating webhook rejecting an invalid specification.
- A quota or cost-control webhook enforcing a limit outside Kubernetes' own quota system.
How to diagnose it
- Read the webhook's name from the error — it is quoted, and it identifies who to ask.
- Find its configuration:
kubectl get validatingwebhookconfiguration NAME -o yaml, which shows what resources and operations it intercepts. - Read the policy itself. For a policy engine this usually means listing its policy custom resources.
- Check the webhook's own logs for more detail than the message carries:
kubectl logs -n WEBHOOK_NS -l app=WEBHOOK. - Test with a minimal object to isolate which field triggers the rejection.
How to fix it
- Change the object so it satisfies the policy. This is almost always the right answer, since the policy was installed deliberately.
- If the policy is wrong, change the policy — through whatever process governs it — rather than bypassing the webhook.
- Use the webhook's documented exemption mechanism if one exists and this case genuinely warrants it.
- Do not remove the webhook configuration to get an object accepted. It disables the policy for everything, not just for you.
Notes
Kubernetes also has built-in Validating Admission Policy using CEL, which enforces rules without an external webhook. A rejection from that has a different message shape and no webhook name, which is a quick way to tell the two apart.
Related
- failed calling webhook — The API server could not reach the webhook
- PodSecurity violation — The pod violates the namespace's security standard
Sources
- Kubernetes documentation — Dynamic Admission Control
- Kubernetes documentation — Admission Controllers Reference