Yes, if the webhook relies on an objectSelector. The Kubernetes docs say to use it only if the webhook is opt in, because end users may skip the webhook by setting the labels. Use admin owned namespace labels for mandatory policy.
Two selectors, two owners
An admission webhook can narrow what it sees. The namespaceSelector matches on the labels of the containing namespace. The objectSelector matches on the labels of the object itself, evaluated against both the new and old object, and it matches if either matches.
The difference is who controls the label. A developer who can create a Deployment can put any label on it. Namespace labels usually need a higher permission.
| Selector | Matches on | Who typically controls it | Good for |
|---|---|---|---|
| namespaceSelector | Labels on the namespace | Admins | Mandatory policy |
| objectSelector | Labels on the object | Whoever creates the object | Opt in features |
The bypass in plain terms
Suppose a policy webhook uses an objectSelector so that it only checks objects labeled for review. An author who wants to avoid the check simply leaves the label off. The docs describe the exact risk: if the selector is used for anything that must be enforced, users can sidestep it.
The docs add a detail: an object that cannot have labels, or a null old object on create, is not considered to match on that side. Selector logic has edge cases, so keep mandatory policy simple.
How to design for enforcement
- Match broadly. Cover all namespaces except a small, named exclusion list.
- Put exclusions in namespaceSelector, and protect who can label namespaces. Test who can edit namespace labels with RBAC checks.
- Do not exclude kube-system by habit. Understand why you do it and what runs there.
- Review failurePolicy at the same time. The default is Fail, which rejects requests when the webhook errors. Ignore lets them through. See webhook timeouts and failure policy tradeoffs.
- Use matchPolicy Equivalent, which the docs recommend so webhooks keep intercepting resources after upgrades enable new versions.
Audit it
List every webhook configuration, read each selector, and ask who can change the labels it depends on. The answer often shows a policy that looks strict and is easy to skip. Related: who can weaken Kubernetes admission controls.
Try it yourself
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the gate applies to every change, not only the ones that ask to be checked.
Quick check
Is objectSelector ever the right choice?
Yes, for opt in features where skipping the webhook is harmless.
What does the namespaceSelector do to cluster scoped objects?
The docs say it has no effect on cluster scoped resources other than Namespace objects.
Safeguard policies and gates apply to every change that passes through them, and a free scan is at https://gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
