A webhook protects only the requests it matches. Three settings decide that: matchPolicy, objectSelector and namespaceSelector. Used carelessly, each can leave a way around your rule. Review them whenever you rely on a webhook for security, and again after each change to its configuration.
matchPolicy: Exact or Equivalent
The docs say matchPolicy defines how a webhook's rules match incoming requests. Allowed values are Exact and Equivalent. Exact intercepts a request only if it exactly matches a rule. Equivalent intercepts a request if it modifies a resource listed in the rules, even through another API group or version.
Equivalent is recommended, and it is the default. Why it matters: the same Deployment can be reached through more than one API version. A rule written for one version should still catch the others.
If you see Exact in a security webhook, ask why.
objectSelector: opt-in only
A webhook can limit which requests it sees by the labels of the object. The docs evaluate the selector against both the new and old object, and a match on either counts.
The warning is the important part: use the object selector only if the webhook is opt-in, because end users can skip the webhook by setting the labels. If your rule is a security control, do not select on a label that a user controls. An attacker who can create the object can leave the label off.
namespaceSelector: scoping by label
For namespaced resources, a webhook can limit requests by the labels of the containing namespace. The docs note that for cluster-scoped resources other than Namespace itself, the selector has no effect.
Gap one: namespaces that lack the label are skipped. Gap two: someone who can patch Namespace objects can change labels. The RBAC good practices page makes the same point for Pod Security admission, noting that users who can patch Namespaces can modify labels, and may configure a more permissive policy than intended.
A review checklist
- Which rules and operations does each security webhook list? Include UPDATE, not only CREATE.
- Is matchPolicy Equivalent?
- Does any selector use a label that users control?
- Which namespaces are excluded, and why? Document each exclusion.
- Who can patch namespaces or edit webhook configurations?
Testing
Try to get past your own rule. Create a test object in a namespace the selector excludes, or with the opt-out label, and confirm what happens. Keep the test in a non-production cluster and record the result as evidence.
Where Safeguard fits
Safeguard cannot see your webhook configuration. It can enforce policies and gates on the manifests in your repositories, and compliance evidence automation can hold your review record.
Why this keeps happening
Selectors are often added to cut noise or to speed up a rollout, and the reason is forgotten later. Add a comment or annotation next to every exclusion in the configuration, with an owner and a date, so the next reviewer can tell a deliberate carve out from an accident.
Quick check
Is objectSelector a safe way to scope a security webhook?
Only if the webhook is opt-in. The docs warn that users can skip it by setting the labels.
Sources
- Dynamic Admission Control, Kubernetes docs
- Role Based Access Control Good Practices, Kubernetes docs
Last reviewed: 19 October 2026.
