Keep an exemption register: one record per exempted namespace, workload or image, each with an owner, a reason, a scope and an expiry date. Review it monthly and remove anything expired. Without that, exemptions added for a deadline stay forever, and your policy quietly stops covering the workloads that most need it.
How exemptions pile up
Admission rules block things, and blocked teams ask for exceptions. The first few are reasonable: a vendor operator that needs a different registry, a legacy service that cannot yet use digests. Each is granted in a hurry and rarely reviewed. A year later the exemption list is longer than the policy.
Kubernetes makes exemptions easy to write. A webhook can limit what it intercepts with a namespaceSelector, which matches on the labels of the containing namespace, so putting a label on a namespace can take it out of scope. Match conditions can also skip requests by expression. Both are legitimate tools, which is why they need governance: whoever can change namespace labels or the webhook configuration can change what is checked. See who can weaken Kubernetes admission controls.
What goes in the register
| Field | Example content |
|---|---|
| Scope | Namespace, workload name, or image digest pattern |
| Rule exempted | Which policy rule, not the whole policy |
| Reason | The business or technical constraint, in one sentence |
| Owner | A named person and a team |
| Compensating control | What reduces the risk meanwhile |
| Approved by | Someone other than the requester |
| Expiry | A date, at most a few months ahead |
| Ticket | Link to the work that removes the need |
The rule exempted matters. Exempting a namespace from "approved registry" should not also exempt it from "no privileged containers".
Make it enforceable
A register on a wiki page drifts. Better to make the register the source of the exemption itself.
- Store exemptions as code in a repository, reviewed by pull request.
- Generate the selectors, labels or parameters from that file.
- Require an expiry field, and fail the build if it is missing or too far out.
- Run a scheduled job that opens a ticket a few weeks before expiry.
- Remove the exemption automatically when the date passes, unless renewed.
Treat renewals as new approvals with a fresh reason, not a rubber stamp.
Limit who can create them
Separate duties. The team requesting an exemption should not be the one approving or applying it. Restrict the RBAC permissions that edit webhook configurations and namespace labels to a small group, and log changes. Audit logs should show who modified the webhook. See Kubernetes audit policy for deployments.
Review rhythm
Monthly, read the register top to bottom. For each entry ask: is the reason still true, is the compensating control working, can the exemption narrow? Count the total and the number past expiry, and include them in your reporting. See five container security numbers to report.
A warning about system namespaces
Cluster components often need exemptions, and teams extend that to "everything in kube-system" or similar. Check what you are skipping. Some system namespaces run workloads you add yourself, such as monitoring agents with broad permissions. Scope by workload where you can.
Where Safeguard fits
Safeguard supports policies and gates with recorded decisions, and exceptions can carry an owner and expiry in the evidence trail. Try a free scan to see what a gate would act on.
Quick check
How long should an exemption last?
As short as the work to remove it, usually weeks to a few months. Anything longer should be a new approval with a fresh reason.
Who should approve exemptions?
Someone other than the requester, ideally from security or platform, with the decision recorded.
Sources
Last reviewed: 19 October 2026.
