Admission rules are only as strong as the permissions around them. Anyone who can edit webhook configurations, or patch namespace labels where Pod Security admission is in use, can loosen your controls. These grants are easy to miss because they do not mention pods or Secrets.
Webhook configuration rights
The RBAC good practices page says users with control over validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that read any object admitted to the cluster. For mutating webhooks, they can also change admitted objects.
Consider what that means. A new mutating webhook can add a sidecar, change an image or inject an environment variable into everything that is created. A change to an existing validating webhook can drop the rule you rely on.
Namespace patch rights
The same page explains that users who can patch Namespace objects, even through a namespaced RoleBinding to a Role with that access, can modify labels on that namespace. Where Pod Security admission is used, this may allow a user to configure the namespace for a more permissive policy than the administrators intended.
Pod Security admission is driven by labels such as pod-security.kubernetes.io/enforce set to a level. Changing that label changes what the namespace accepts.
Other label based features
The docs give a second example. For clusters using Dynamic Resource Allocation, labeling a namespace with resource.kubernetes.io/admin-access set to true lets any user who can create ResourceClaims there request admin access to devices already allocated to any other claim in any namespace. Labels are policy inputs, so label permissions are policy permissions.
What to do
- Search roles for the two webhook configuration resources and for patch or update on namespaces. Include wildcards.
- Restrict those grants to a small platform group, with no service accounts used by ordinary workloads.
- Do not exempt controller service accounts from Pod Security admission to work around problems. The docs warn that exempting them would implicitly exempt any user who can create the matching workload.
- Audit changes to the configurations and to namespace labels. See our posts on admission webhook matching gaps for related review steps.
- Keep the intended labels in version control, and alert on drift.
A simple test
Ask: if one namespace admin account were compromised, could the attacker make the namespace more permissive for pods? If yes, the label is not protected.
Safeguard does not manage cluster RBAC. Policies and gates can help by checking that namespace manifests in your repositories carry the expected labels, and compliance evidence automation keeps the access review record.
Detecting a change after the fact
Prevention is better, but also watch for changes. Send audit events for webhook configurations and namespace updates to a place the platform team reads. A change to a security webhook outside a planned window deserves a same-day look. Keep a reviewed copy of the intended configuration in version control and compare it to the live objects on a schedule.
Quick check
Does patch on namespaces matter if the role is namespaced?
Yes. The docs say a namespaced RoleBinding to a Role with patch on Namespace objects is enough to change that namespace's labels.
Sources
Last reviewed: 19 October 2026.
