Not Just a Bouncer — Also a Fixer
So far, Gatekeeper has acted purely as a validator: allow or deny. But Gatekeeper also supports Mutation via a separate admission webhook — a MutatingWebhookConfiguration. Instead of rejecting a request, a mutation automatically modifies the resource before it's stored.
Common Mutation Use Cases
- Inject a sidecar: Automatically add a logging or security sidecar container to every Pod in a namespace.
- Set default resource limits: If a Pod doesn't specify CPU limits, automatically set them to a safe default rather than rejecting the Pod.
- Add labels: Automatically stamp every resource with a
managed-by: platform-teamlabel for inventory tracking. - Override image registries: Rewrite
docker.io/nginx:latesttoregistry.internal.company.com/nginx:latest.
Mutation vs. Validation: When to Use Each
| Scenario | Use Validation | Use Mutation |
|---|---|---|
| Security boundary (must never be violated) | ✅ Deny the request | ❌ Don't silently fix security issues |
| Developer convenience (sensible defaults) | ❌ Don't block for missing defaults | ✅ Inject the default automatically |
| Compliance labeling | Either — deny if missing, or auto-add | ✅ Auto-add is less friction |
Important nuance: Mutations run before validations in the admission chain. This means you can mutate a resource into compliance and then validate it — a powerful pattern for "fix what you can, reject what you can't."