Admission webhook timeouts and failure policy: fail open or fail closed?

When an admission webhook times out or cannot be reached, Kubernetes follows the webhook's failure policy. Fail rejects the request, which is safe but can block deployments. Ignore lets it through, which keeps the cluster working but skips your check. Choose per rule, and keep timeouts short.

What the docs say

The default timeout for a webhook call is 10 seconds. The docs encourage short timeouts, and their example uses timeoutSeconds set to 5. If the call times out, the request is handled according to the webhook's failure policy.

In the match condition examples, the docs label Ignore as fail-open and Fail as fail-closed, and mark Fail as the default. I could not read the full failure policy section, so check it in the current docs before you rely on exact semantics.

The tradeoff

• Fail closed: a webhook outage blocks every matching create or update. For a control like "no privileged pods", that is the safe behavior.
• Fail open: an outage silently disables the control. An attacker, or just a bad day, could produce the outage.

Neither choice is free. Fail closed turns an availability problem in your webhook into an availability problem for the cluster. Fail open turns it into a security gap.

Decision guide

Use fail closed when:

• the rule blocks something dangerous, such as host access or untrusted images;
• the webhook runs with several replicas and a disruption budget;
• you scope it so it cannot block its own deployment.

Use fail open when:

• the webhook is advisory, such as labeling or defaulting;
• the rule is new and still being tuned.

Reduce the blast radius

Narrow what the webhook matches. The docs describe namespaceSelector to limit requests for namespaced resources by namespace label, and objectSelector to limit by object label. They warn that you should use the object selector only if the webhook is opt-in, because end users can skip the webhook by setting the labels.

Also exclude the namespace where the webhook itself runs. Otherwise a restart of the webhook pod can be blocked by the webhook. This is a general operating practice, so test it in a non-production cluster.

Think about alternatives

A declarative validating policy runs inside the API server, so there is no external server to time out. It still has its own failurePolicy, which matters for broken expressions. See our post on rolling out admission policy with Warn and Audit first.

Monitoring

Alert on webhook latency and error rates, not only on rejections. A webhook that is failing open produces no rejection events at all.

Safeguard cannot run or monitor your cluster webhooks. It can apply policies and gates to the manifests before they get there, which gives you a second line when admission is degraded.

Quick check

Sources

• Dynamic Admission Control, Kubernetes docs
• Validating Admission Policy, Kubernetes docs

Last reviewed: 19 October 2026.