How do you detect Kubernetes admission controller modifications?

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.

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?