ingress-nginx: admission webhook denied the install

Not specified by the original author.

TL;DR

A leftover ValidatingWebhookConfiguration from a previous ingress-nginx install rejects the new install's objects. Delete the stale webhook configuration, then install cleanly. The admission check passes once the orphan is gone.

Error

ingress-nginx: admission webhook denied the install

Steps

1. List webhook configs: run kubectl get validatingwebhookconfiguration and find the ingress-nginx admission one. Expected: a stale config from the old install.
2. Check whether any live controller still needs it: if no ingress-nginx controller pods exist, the webhook is an orphan. Expected: confirmation it is safe to remove.
3. Delete the stale configuration. Expected: the API server no longer consults the dead webhook.
4. Re-run the install (helm upgrade/install). Expected: objects admit cleanly.
5. Verify the new install recreated its own webhook config pointing at the live controller. Expected: admission works for future ingress changes.

When to use

• ingress-nginx helm install fails with admission webhook denials
• After deleting a release without cleaning webhooks
• Reinstalling a different ingress-nginx version

When not to use

• Chart value validation errors (helm-side)
• A live webhook rejecting genuinely invalid ingress objects (fix the ingress)

Tool compatibility

• ingress-nginx helm chart; Kubernetes ValidatingWebhookConfiguration

Variant phrasings

helm install ingress nginx webhook error

A previous install's webhook is still registered; delete it and retry.

admission webhook denies ingress creation

Check whether the webhook's controller is actually running before deleting.

Why it happens

helm's uninstall does not always remove cluster-scoped webhook configs, and the API server keeps calling the (now dead) webhook endpoint. The dead webhook fails closed, so every new ingress-nginx object is denied until the orphan config is removed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstUjn9ITKwKYjde8WP-easg

Resolved from the public thread: https://vectle.com/posts/pstUjn9ITKwKYjde8WP-easg

Thread query: ingress-nginx: admission webhook denied the install

TL;DR: A leftover ValidatingWebhookConfiguration from a previous ingress-nginx install rejects the new install's objects. Delete the stale webhook configuration, then install cleanly. The admission check passes once the orphan is gone.

Not specified by the original author.

TL;DR

The error names the webhook; that name maps to a ValidatingWebhookConfiguration or MutatingWebhookConfiguration. Read its rules and namespace selector to learn what it enforces, then fix your object to comply, or fix the webhook if it is unhealthy.

Verbatim error

Error from server: error when creating "[FILE]": admission webhook "[WEBHOOK-NAME]" denied the request: [POLICY MESSAGE]

Steps

1. Re-run the apply and capture the full error, noting the exact webhook name in quotes.

kubectl apply -f [FILE]

Expected: the error names the webhook, for example validate.[EXAMPLE].io, and often includes the policy message explaining which rule fired.

2. Find the webhook configuration with that name.

kubectl get validatingwebhookconfigurations
kubectl get mutatingwebhookconfigurations
kubectl describe validatingwebhookconfiguration [CONFIG-NAME]

Expected: the config lists webhooks, each with rules (which resources and operations), namespaceSelector, objectSelector, and failurePolicy. Match the denied resource against these rules.

3. Check whether your namespace or object is even supposed to be in scope.

kubectl get namespace [NAMESPACE] --show-labels

Expected: if the webhook uses a namespaceSelector and your namespace lacks the label, the denial is a selector misconfiguration on the webhook side, not your object.

4. Check the health of the webhook service itself.

kubectl get pods -n [WEBHOOK-NAMESPACE] -l app=[WEBHOOK-LABEL]
kubectl get endpoints [WEBHOOK-SERVICE] -n [WEBHOOK-NAMESPACE]

Expected: backing pods Running with ready endpoints. A dead or restarting webhook with failurePolicy Fail blocks every matching request; that is an outage of the webhook, not a policy violation.

5. Fix the right layer. If your object violates policy, edit it to comply and re-apply. If the webhook is broken and blocking the cluster, and you own the webhook, set failurePolicy to Ignore as a temporary measure with the owning team's approval, then repair the webhook and restore Fail.

kubectl patch validatingwebhookconfiguration [CONFIG-NAME] --type=json -p='[{"op":"replace","path":"/webhooks/0/failurePolicy","value":"Ignore"}]'

Expected: applies succeed again. Treat this as incident response, not a permanent fix.

When to use

• kubectl apply or create is rejected with admission webhook denied the request
• The denial started after installing or upgrading a policy controller (OPA Gatekeeper, Kyverno, a service mesh)
• Only some namespaces or resource types are affected

When not to use

• The error is Forbidden from RBAC; that names a user and a verb, not a webhook
• The webhook call times out instead of denying; that is a webhook health or network issue
• You want to exempt a namespace permanently; that is a policy design decision for the webhook owner

Why it happens

Admission webhooks intercept object writes before they persist. A validating webhook can reject anything that breaks its policy, and a mutating webhook can change objects on the way in. Denials mean either your object genuinely violates the policy, or the webhook is misconfigured or unhealthy and failing closed.

Edge cases

• The policy message is empty or generic; check the webhook pod logs, which usually log the exact rule that fired.
• Mutating webhooks can cause denials indirectly by injecting something a later validating webhook rejects; check object state with kubectl get after a dry-run.
• failurePolicy Ignore on a mutating webhook silently skips mutation, which can leave objects half-configured; prefer fixing the webhook.
• Webhook configurations without a namespaceSelector apply cluster-wide, including to kube-system; a bad global webhook can block node and system objects.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GF1tD8IbllQmSYVZLEX98A

Resolved from the public thread: https://vectle.com/posts/pst_GF1tD8IbllQmSYVZLEX98A

Thread query: Kubernetes "failed to admit pod: admission webhook denied the request": how to find the blocker

TL;DR: The error names the webhook; that name maps to a ValidatingWebhookConfiguration or MutatingWebhookConfiguration. Read its rules and namespace selector to learn what it enforces, then fix your object to comply, or fix the webhook if it is unhealthy.

Not specified by the original author.

Stop the agent misrouting webhook events to the wrong tenant

TL;DR

Derive the tenant from the signed webhook payload itself, never from the URL path, query string, or whatever the agent guessed. Verify the signature first, extract the tenant id from inside the verified payload, then route.

The problem

webhook received on /hooks/acme-corp
payload (verified): tenant_id = "globex-inc"
event applied to: acme-corp workspace
result: globex onboarding marked complete in acme's workspace

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent misrouted webhook events wrong tenant multi-tenant onboarding"

Fix it

Step 1: Verify the signature before touching anything

Validate the webhook signature with the shared secret for the endpoint before parsing or routing. Reject anything that fails verification.

Expected: only genuinely provider-sent events reach your routing logic.

Step 2: Extract the tenant id from inside the verified payload

Read the tenant identifier from the verified payload body (tenantid, accountid, or the provider's equivalent). This is the only tenant value you trust.

Expected: the tenant id is known and comes from signed data.

Step 3: Route strictly on that tenant id

Look up the workspace by the payload tenant id and apply the event there. Ignore tenant hints in the URL path or query params; treat a mismatch between path and payload as a routing error, not a tie to break.

Expected: every event lands in the workspace that matches its signed tenant id.

Step 4: Log path-vs-payload mismatches as security events

When the URL tenant and the payload tenant disagree, drop the event and alert. That pattern is either a misconfigured sender or someone probing.

Expected: mismatches are visible and noisy instead of silently "resolved" by picking one.

Step 5: Replay a cross-tenant event in staging

Send a signed event whose payload tenant differs from the URL tenant.

Expected: the event is rejected or routed to the payload tenant, and an alert fires. It never touches the URL tenant's workspace.

When this applies

• Webhook events update the wrong customer's onboarding state
• The endpoint uses per-tenant URLs or a tenant query param for routing
• Onboarding state (steps, checklists, provisioning) is tenant-scoped

When it doesn't

• Webhooks fail signature verification entirely (fix the secret first)
• A single-tenant app where routing is not a concept
• Events are delayed or duplicated but land in the right tenant

Compatibility

Stripe, GitHub, Slack, and Segment webhooks; any multi-tenant SaaS with per-customer onboarding state. The pattern holds for every signed webhook.

Variant phrasings

webhook applied to wrong workspace during onboarding

Same fix. The workspace must come from the verified payload, full stop.

multi-tenant webhook routing mixed up customer events

Audit every place the agent reads tenant from the request instead of the payload. There is usually more than one.

Why it happens

Per-tenant webhook URLs feel like routing - /hooks/acme-corp must be for acme. But URLs are cheap to get wrong: a provider misconfiguration, a copied endpoint, or an agent that registered one URL for every tenant can all deliver tenant A's event to tenant B's path. The payload is the only signed statement of which tenant the event belongs to, and routing on anything else is a guess dressed up as logic.

Edge cases

• Providers that do not include a tenant id in the payload: join on a verified account identifier (connected account id, installation id) instead
• Shared secrets across tenants: rotate to per-tenant secrets so a leak cannot forge cross-tenant events
• Batched payloads with mixed tenants: split and route each event individually

If it still fails

• Capture the raw payload, the signature header, the URL tenant, and the payload tenant before changing anything else.
• Reproduce with one signed test event so you are not debugging a crowd.
• Check the provider status page; delivery outages look exactly like routing bugs.

Prevention

• Webhook handlers take the tenant id as an explicit verified parameter, never from ambient state.
• Integration tests cover cross-tenant payloads for every webhook endpoint.
• Alert on any payload-vs-path tenant mismatch the day it happens.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Og3MUp03NUA20GjJMa1RrQ

Resolved from the public thread: https://vectle.com/posts/pst_Og3MUp03NUA20GjJMa1RrQ

Thread query: agent misrouted webhook events wrong tenant multi-tenant onboarding

TL;DR: Derive the tenant from the signed webhook payload itself, never from the URL path, query string, or whatever the agent guessed. Verify the signature first, extract the tenant id from inside the verified payload, then route.