Detect them by alerting on changes to admission webhooks, mutating or validating policies, and related configuration objects. Review who made the change, whether the endpoint or rules changed, and whether the controller could now alter or block pods unexpectedly. Because admission controllers influence what gets admitted into the cluster, any unplanned modification should be treated as high risk.
What to look for when admission control changes in Kubernetes
admission controller modifications are easiest to spot when you watch the Kubernetes API for updates to mutating and validating webhooks, admission policy objects, and the configuration that points to them. The useful question is not only whether something changed, but whether the cluster now routes admission decisions to a different service, applies new rules, or stops enforcing a rule that previously existed.
Because admission happens before an object is persisted, these changes can alter what gets into the cluster even when the workload itself has not changed. That makes configuration drift in this area especially important to detect quickly, since a small edit can affect pod creation, namespace behaviour, label enforcement, or image admission across many workloads at once.
Detection should therefore focus on the object layer and the control-plane effect together: who changed the resource, what field changed, and whether the new configuration expands, weakens, or redirects admission logic. The most actionable signal is a change that gives a controller new authority over pod creation or removes an existing guardrail without an expected change window.
Which Kubernetes objects matter most
The core watchlist includes Kubernetes Security Guide coverage of admission control, because admission webhooks and policy systems sit alongside other cluster-hardening controls. If you are only watching deployment manifests, you can miss the objects that actually decide whether a manifest is admitted.
Review changes to ValidatingWebhookConfiguration and MutatingWebhookConfiguration, plus any policy engine objects such as ValidatingAdmissionPolicy or Gatekeeper and Kyverno resources if they are in use. A modification to the webhook service name, URL, CABundle, failure policy, namespace selector, object selector, or rules can be more important than a simple spec edit, because it changes which requests are intercepted and how the API server behaves when the controller is unavailable.
It also helps to compare the new admission path with the old one. A webhook that now matches more resource kinds, more namespaces, or broader operations may create a larger blast radius, while a webhook that no longer matches expected resources may quietly stop enforcing a critical control.
How to tell whether the change is suspicious
A change deserves immediate scrutiny when it appears outside an approved rollout, is made by an unexpected principal, or coincides with unusual API activity. If the modification came from an account that does not normally manage cluster policy, treat it as a governance and privilege event as well as a configuration event.
Useful triage questions are simple: did the endpoint change, did the rules change, did the failure mode change, and did the object selection change. A rule expansion can let the controller mutate or deny more resources than intended, while a failure policy shift can turn a temporary webhook outage into an admission bypass or cluster outage depending on the setting.
The risk is not limited to malicious edits. A well-intentioned change can still create outages if the webhook endpoint is unreachable, if certificate trust breaks, or if the policy becomes too broad for the controller to process reliably. That is why admission changes should be reviewed both for integrity and for availability impact.
Risk and Threat Considerations
Admission controllers are high-value because they sit on the path between a request and a persisted Kubernetes object. A hostile or mistaken modification can be used to weaken policy enforcement, introduce unauthorized pods, or block legitimate workloads at scale.
Failure mechanism: The attacker or operator changes webhook routing, matching rules, or failure handling so the API server no longer applies the intended validation or mutation. That can create a bypass, a denial condition, or a hidden policy change that only appears when new workloads are deployed.
Impact: The cluster may admit unsafe workloads, lose protection against prohibited configuration, or become unavailable to legitimate deployments. In a managed environment, this can also invalidate change-control assumptions and obscure the point at which the cluster’s admission posture changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Admission controller changes require auditable change records for who changed what. |
| CM-3 — Configuration Change Control | Webhook and policy edits are control-plane configuration changes that need authorization. | |
| AC-6 — Least Privilege | Only a small set of admins should be able to modify cluster admission controls. | |
| Recommendation — Log webhook and policy modifications with actor identity and object detail. Require approval for admission control changes before deployment. Restrict admission policy editing to tightly scoped admin roles. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Admission controller drift is a secure-configuration issue in the cluster control plane. |
| Recommendation — Continuously monitor Kubernetes admission objects for unauthorized configuration drift. | ||
| NIST CSF 2.0 | DE.CM-03 — Personnel Activity and Security Alerting | Alerting on unauthorized cluster policy edits is part of continuous monitoring. |
| Recommendation — Alert on changes to admission control objects and their effective scope. | ||
Practitioner Guidance
What to verify: Confirm that audit logs capture both the object write and the actor identity, then compare the before and after state of the webhook or policy object, not just the timestamp of change. The most important validation is whether the new configuration still enforces the same scope, failure behaviour, and trust boundary.
Decision rule: If the change can alter which pods are admitted, treat it as a security-relevant control change and escalate it for review before approving the rollout. If the change only updates a label, annotation, or non-functional field, it still deserves review, but the response can usually be proportionate to the actual enforcement effect.
Practitioner takeaway: For admission control, the right detection signal is not “something in Kubernetes changed”, it is “something that changes who can pass or block workload admission changed”, because that is where the security impact lives.
Related resources from NHI Mgmt Group
- How should teams reduce the blast radius of a vulnerable Kubernetes ingress admission controller before patching is complete?
- How should Kubernetes teams respond when ingress-nginx exposes a cluster takeover path through admission controller vulnerabilities?
- Why does exposing the ingress-nginx admission controller create such a high-risk path for Kubernetes clusters?
- What is the difference between admission controller image signature validation and runtime-based validation in Kubernetes?