# Distinguish webhook call failures from explicit Kubernetes admission denials > Test failurePolicy handling separately from a successfully delivered webhook response containing allowed: false. - Canonical URL: https://update.dsesecurity.com/updates/distinguish-webhook-call-failures-from-explicit-kubernetes-admission-denials/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:31+00:00 - Modified: 2026-10-30T06:05:14+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Test failurePolicy handling separately from a successfully delivered webhook response containing allowed: false. ## Potentially affected Kubernetes validating admission webhooks and their failure-policy reviews. ## DSE recommendation Exercise a deliberate policy denial separately from timeout or connection-failure handling. ## Article Bottom line: Give a webhook outage and an intentional policy denial different acceptance cases. Write the expected admission decision for each before choosing or changing the webhook’s failure policy. ## Source fact: documented behavior The [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) documentation is the primary reference. A webhook response uses an AdmissionReview response with the request UID and an allowed value of true or false. The webhook failure policy handles errors while calling the webhook; Ignore continues the API request after such an error, while Fail rejects it. A correctly transmitted explicit allowed: false response denies the request regardless of the failurePolicy value. The timeout setting determines how long the API server waits for a response before applying failure-policy handling. ## What the source does not establish This article separates a delivered policy decision from call-error handling. It does not select a universal fail-open or fail-closed policy, approve webhook deployment or describe the separate authentication-token mechanism. Keep request matching and mutation composition under their own reviews. ## Applicability questions - Which harmless request should the policy explicitly reject? - What should happen if the webhook cannot be reached or exceeds its timeout? - Which observed response distinguishes those cases? - Who owns the availability and policy consequences of the proposed failure setting? ## DSE recommendation: write a two-axis admission test DSE recommends a test matrix with the intended policy decision in one dimension and webhook availability in the other. Start with an allowed fixture and a denied fixture, both reaching the test webhook normally. Record the selected webhook configuration and the exact request match so a skipped call cannot be mistaken for an allowance. Keep a separate call-failure case. Have the cluster and policy owners agree which connection or timeout condition may be simulated in an isolated environment. Set the expected admission outcome from the reviewed failure policy before running it. Do not change a shared production endpoint simply to create an outage demonstration. Retain the actual response and diagnostic category for each case. Distinguish an AdmissionReview policy rejection from a transport failure, malformed response or timeout. Preserve the UID relationship and sanitized request identity where available through the approved harness. Investigate a missing response rather than treating an error message alone as the policy’s decision. Review the operational choice with both owners. State which availability loss and which policy bypass consequence the organization is accepting. Keep any proposed configuration correction reversible and tied to the observed test category. Avoid weakening failure handling to solve a deliberate denial that the policy owner still requires. ## Verification and evidence Proposed verification, not performed: use an isolated test webhook and disposable requests. Observe an explicit allow and an explicit denial with the service healthy. Compare each actual AdmissionReview result with the written policy expectation. Then exercise the approved unreachable or timeout case under the selected failure setting, without changing the test policy’s denial rule. Retain the configuration, matching request, response or call error, timing observation and API result. If a second failure setting is evaluated, record it as a separate reviewed case. Report only the exercised distinction; keep cluster-wide availability and application policy coverage outside that result. ## Official references - [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) — Kubernetes. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Dynamic Admission Control - Authority: kubernetes.io - URL: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish webhook call failures from explicit Kubernetes admission denials,” DSE Security, https://update.dsesecurity.com/updates/distinguish-webhook-call-failures-from-explicit-kubernetes-admission-denials/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.