Build the bypass into the policy ahead of time. Kubernetes lets a validating webhook skip requests from users who hold a specific permission, so an on-call engineer can push a fix through while every use is attributable and logged. The alternative, deleting or disabling the webhook at 2 a.m., is worse in every way.
Why you need a planned bypass
Image admission rules block deployments that fail policy: unapproved registries, missing signatures, critical findings. Sooner or later a rule will block the one deployment you must make, such as a hotfix for an outage. If there is no sanctioned route, people will find an unsanctioned one. They will edit the webhook configuration, set it to fail open, or relabel a namespace. Each of those weakens the control for everyone and leaves little record.
The mechanism Kubernetes documents
The Kubernetes dynamic admission control documentation includes a match condition example named breakglass. It skips requests made by users who are authorized to perform a breakglass verb on that webhook, using an authorizer check. The page notes that the breakglass verb does not need to exist outside this check. It is simply a permission you grant through RBAC.
In outline:
matchConditions:
- name: 'breakglass'
expression: '!authorizer.group("admissionregistration.k8s.io").resource("validatingwebhookconfigurations").name("my-webhook.example.com").check("breakglass").allowed()'
Check the documentation for your cluster version before copying it, since match conditions depend on the version and feature status.
Design the process around it
| Element | Recommendation |
|---|---|
| Who holds the permission | A small on-call group, not all developers |
| How it is granted | Time-boxed role binding, ideally requested and approved |
| What is logged | Every bypassed request, with user and image digest |
| Follow-up | A ticket opened automatically, reviewed within a set time |
| Cleanup | Role binding expires, finding is fixed or accepted with expiry |
Pair this with audit logging so the bypass is visible afterwards. See Kubernetes audit policy for deployments.
Failure policy is a separate question
Break-glass is about people. Failure policy is about the webhook being unavailable. The same documentation shows both settings: Fail, which is the fail-closed default, and Ignore, which fails open. Do not use Ignore as your emergency plan. Decide failure policy on its own merits. See admission webhook timeouts and failure policy.
Test it before you need it
- Create a test namespace and a policy that blocks a known bad image.
- Confirm a normal user is blocked.
- Grant the break-glass permission to a test user and confirm the deploy passes.
- Confirm the audit log shows who did it.
- Revoke the permission and confirm the block returns.
Run this drill twice a year. A bypass that has never been exercised often fails when it matters.
Where Safeguard fits
Safeguard provides policies, gates and guardrails, and records decisions as evidence, which suits the follow-up review that a break-glass event needs. Try a free scan to see findings for an image you would gate.
Quick check
Is break-glass the same as fail open?
No. Fail open lets all requests through when the webhook errors. Break-glass lets specific authorized users through while the policy still runs for everyone else.
Who should hold the break-glass permission?
A small on-call group, granted for a limited time, with every use logged and reviewed.
Sources
Last reviewed: 19 October 2026.
