Admission Controller Coverage Calculator

Coverage = namespace coverage × 0.45 + enforcing-policy share × 0.35 + exemption score × 0.20 − failure-policy penalty, where exemption score = max(0, 100 − 3 × exempted namespace percentage). Three things decide whether admission control is real: how much of the cluster it sees, whether it denies or merely warns, and what happens when the webhook is down. failurePolicy: Ignore is scored as a flat 20-point penalty because it converts every policy into a suggestion during exactly the window an attacker would exploit — and a busy cluster has that window regularly.

Admission control is the only Kubernetes control that prevents rather than reports, and most installations run in audit mode with failurePolicy: Ignore, which is a dashboard rather than a guardrail.

This calculator takes 10 inputs: Namespaces in the cluster, Namespaces covered by a policy, Policies defined, Policies in enforce or deny mode, Namespaces exempted from policy, Admission requests per day, Requests denied per day, Webhook p95 latency, Webhook timeout, Webhook failure policy. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Yes, with preparation. Exempt kube-system and your policy controller's own namespace, run at least two webhook replicas across nodes, keep the timeout modest, and load-test admission latency. Done that way, Fail is safe and Ignore is the risk — because a crash-looping webhook silently disables every policy you have.

Yes, briefly. Audit tells you what would break without breaking it, which is essential for a policy applied to running workloads. The failure is leaving them there: set a date when each policy is promoted to enforce, and track the enforce ratio so the intention does not quietly expire.