Extensión del servidor de API con webhooks de admisión

After authentication and authorization, requests pass through admission controllers that can validate or modify objects before they are persisted.

Dynamic admission uses webhooks: mutating webhooks change objects, and validating webhooks accept or reject them.

The API server runs mutating webhooks first, then validating webhooks, so a mutation can add defaults before validation checks the final object.

Examples: inject a sidecar (mutating), enforce that every Pod sets resource limits (validating), or block images from untrusted registries.

This resource registers your webhook endpoint with the API server.

The API server sends an AdmissionReview JSON to your webhook and expects an AdmissionReview response with allowed true/false, and for mutation a JSONPatch.

A mutating webhook returns a base64-encoded JSONPatch describing the changes to apply.

failurePolicy: Fail blocks requests if the webhook is down, which is safe but can lock up the cluster; Ignore lets requests through, which is risky for security policies.

Use namespaceSelector and objectSelector to limit which requests hit your webhook, avoiding overhead and accidental scope creep.

Instead of writing webhook servers, tools like OPA Gatekeeper and Kyverno provide declarative policies on top of the same admission mechanism.

Webhook endpoints must serve HTTPS with a certificate trusted via the caBundle, since the API server only calls webhooks over TLS.

You learned how admission webhooks extend the API server: mutating webhooks change objects and validating webhooks enforce policy, the AdmissionReview flow, failurePolicy and selectors, TLS requirements, and policy engines like Kyverno and Gatekeeper.