Webhook security & bypasses

failurePolicy, exclusions, and the webhook as target.

An admission webhook is only as strong as its own security and configuration. Attackers who understand webhooks target exactly the settings that turn a policy gate into a policy gap — the failure behavior, the exclusions, and the webhook service itself.

failurePolicy and the availability tradeoff

Every webhook has a failurePolicy that decides what happens when the webhook service is unreachable. Ignore admits requests unchecked when the webhook is down — which means an attacker who can disrupt or overload the webhook simply bypasses the policy. Fail blocks admissions when the webhook is unavailable, which is secure but couples cluster availability to the webhook’s uptime. For security-critical policy, prefer Fail and invest in making the webhook highly available (multiple replicas, tight timeouts, health checks); using Ignore for a security control is trading enforcement for convenience in exactly the moment an attacker wants.

webhooks:
  - name: verify.acme.io
    failurePolicy: Fail          # secure: do not admit if the webhook is down
    timeoutSeconds: 5            # keep tight, but HA the service so Fail is safe
    namespaceSelector:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: [kube-system]   # ⚠ every exclusion is a potential bypass —
                                   #    can an attacker place a workload here?
    rules:
      - operations: [CREATE, UPDATE]
        resources: [pods]

Exclusions and protecting the webhook

Namespace and object exclusions are the other common weakness: a policy that skips kube-system (or any namespace) is bypassed by anything an attacker can place there, so keep exclusions minimal and deliberate. And the webhook service itself is a high-value target — it sees every matching object and its verdict is trusted, so compromising it lets an attacker weaken policy or exfiltrate admitted objects. Protect it like control-plane infrastructure: least-privilege RBAC, restricted network access, and tight control over who can create or modify ValidatingWebhookConfiguration/MutatingWebhookConfiguration objects, because a malicious mutating webhook can silently backdoor every pod in the cluster.