auditing-admission-control-policy-gapslisted

# Auditing admission control policy gaps: when the gatekeeper waves it through Admission control is the cluster's gate: every create and update passes through validating and mutating webhooks that are supposed to reject workloads that break policy, privileged pods, unsigned images, over-broad service accounts, host mounts. The gate only protects the cluster if it actually fires on the requests that matter and cannot be skipped. In practice it is riddled with quiet gaps: a webhook configured to fail open so an unreachable backend admits everything, a policy scoped to some namespaces but not the one an attacker targets, an exemption for system workloads that a hostile pod can wear, and a mutating webhook whose output later stages trust without re-validating. A gate with a gap is worse than no gate, because teams believe it is enforcing. You audit this by checking, for each policy, whether it fires on every relevant request and whether anything can bypass it. ## When to use - Admission webhooks or a policy engine are the control keeping non-compliant workloads out of the cluster. - Webhooks may fail open, be scoped narrowly, carry exemptions, or run in an order that allows a bypass. - A mutating webhook changes resources that later stages or other policies trust without re-checking. ## Scope check Test admission control only on clusters you own or are authorized to assess, on non-production namespaces. Probing a policy means submitting workloads to a real cluster, so use a