Kubernetes Validating Admission Management

Kubernetes Validating Admission Management is the practice of configuring and operating the webhooks and built-in plugins that make the final accept-or-reject decision on an API object, running after every mutating admission step has completed. Unlike mutating admission, a validating webhook cannot alter the object it inspects — it can only approve or deny — which makes it the enforcement point for policies where the requirement is compliance with a rule, not automatic correction.

How Validating Webhooks Decide

Allow or Deny, No Modification

A validating webhook's AdmissionReview response contains only an allowed boolean and an optional status message; unlike a mutating webhook, it has no mechanism to patch the object, so any policy requiring automatic correction rather than outright rejection belongs in the mutating phase instead.

{
  "response": {
    "uid": "705ab4f5",
    "allowed": false,
    "status": {
      "message": "containers must not run as root (runAsNonRoot required)",
      "code": 403
    }
  }
}

All Matching Webhooks Must Agree

Every validating webhook matching a given request is invoked, and the request is only admitted if all of them return allowed: true; a single rejection from any matching webhook fails the entire request, which means validating webhooks compose as a logical AND rather than needing explicit coordination between separately authored policies.

Common Validation Policy Categories

Pod Security Requirements

Rejecting pods that request privileged: true, set hostPID or hostNetwork, or omit runAsNonRoot in namespaces where such configurations are disallowed is among the most common validating admission use cases, often implemented through the built-in PodSecurity admission controller rather than a custom webhook.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Resource and Configuration Requirements

Custom validating policies frequently require that every container specify resource requests and limits, that images reference a specific digest rather than a mutable tag, or that required labels are present for cost allocation and ownership tracking.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
  - name: no-latest
    match:
      resources:
        kinds: ["Pod"]
    validate:
      message: "image tag 'latest' is not allowed"
      pattern:
        spec:
          containers:
          - image: "!*:latest"

Enforcement Modes and Gradual Rollout

Audit and Warn Before Enforce

Many validating admission systems, including the built-in PodSecurity controller, support audit and warn modes alongside enforce, allowing a new policy to be observed against real traffic — logging or warning about violations without blocking them — before switching to strict enforcement once the policy's real-world impact is understood.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Exempting Specific Cases Deliberately

Rather than weakening a policy globally to accommodate a small number of legitimate exceptions, scoping validation with namespaceSelector or objectSelector to exclude specific, explicitly labeled cases keeps the general policy strict while documenting exactly which workloads are exempted and, implicitly, why.

Operational Considerations

Timeout and Latency Budget

Every validating webhook invocation adds latency to the request path, and because all matching webhooks must be evaluated (not short-circuited on the first pass), the cumulative latency across many registered validating webhooks with overlapping scope can become a meaningful contributor to API responsiveness under load.

failurePolicy for Validating Webhooks

The choice between failurePolicy: Fail and failurePolicy: Ignore is particularly consequential for validating webhooks enforcing security baselines: Ignore means a webhook outage silently allows policy-violating objects through, while Fail means the outage blocks all matching deployments entirely — a decision that should reflect the relative cost of a security gap against the cost of a deployment freeze for the specific policy in question.

Auditing Validation Coverage

Confirming Policies Actually Fire

Testing a validating webhook against deliberately non-compliant test objects in a staging environment confirms the policy actually rejects what it is designed to reject, since a webhook with an incorrect rule matcher or a bug in its validation logic can silently pass everything through despite appearing correctly configured.

Reviewing the Full Set of Active Validators

Periodically enumerating every active ValidatingWebhookConfiguration alongside enabled built-in validating plugins clarifies the cluster's actual enforced policy surface, which is frequently narrower in practice than the union of policies teams believe are being enforced.