Skip to content
ENExplore Calculators

Admission Controller Coverage Calculator

Score admission control coverage from namespaces under policy, enforce versus audit mode, exemptions, webhook failure policy and latency budget.

About Admission Controller Coverage Calculator

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.

Formulas

Admission Controller Coverage

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).

namespaceCoverage
Namespaces under at least one policy ÷ all namespaces × 100
enforceRatio
Policies in enforce mode ÷ all policies × 100
failurePolicy
20-point penalty while the webhook fails open

Latency headroom

Timeout budget used = webhook p95 latency ÷ (timeout × 1000) × 100. Past roughly 50%, normal load variance starts producing admission timeouts.

p95LatencyMs
95th percentile webhook response time
webhookTimeoutSeconds
Configured webhook timeout, maximum 30 seconds

Worked example

With the default values below, Admission Controller Coverage Calculator returns Admission Coverage Score of 40.4. Change any input above and every figure here is recalculated in your browser.

Inputs used

Namespaces in the clusteraccepts 1–20,000 namespaces
64 namespaces
Namespaces covered by a policyaccepts 0–20,000 namespaces
46 namespaces
Policies definedaccepts 1–20,000 policies
38 policies
Policies in enforce or deny modeaccepts 0–20,000 policies
21 policies
Namespaces exempted from policyaccepts 0–20,000 namespaces
12 namespaces
Admission requests per dayaccepts 0–1,000,000,000 requests
180,000 requests
Requests denied per dayaccepts 0–1,000,000,000 requests
940 requests
Webhook p95 latencyaccepts 0–60,000 ms
38 ms
Webhook timeoutaccepts 1–30 seconds
10 seconds
Webhook failure policyone of Fail — closed, requests denied if the webhook is down — 0, Ignore — open, requests admitted if the webhook is down — 20
Ignore — open, requests admitted if the webhook is down — 20

Results

Admission Coverage Score
40.4 / 100
Grade
D — Weak
Namespace Coverage
71.9%
Policies Actually Enforcing
55.3%
Exempted Namespace Share
18.8%
Namespaces With No Policy
18 namespaces
Admission Denial Rate
0.522%
Timeout Budget Used at p95
0.38%
Verdict
failurePolicy: Ignore means every policy is optional whenever the webhook is unhealthy — move to Fail with a tested exemption list

Step by step

  1. 1Values used
  2. 2Admission Controller Coverage
  3. 3Latency headroom
  4. 4Admission Coverage Score= 40.4 / 100
  5. 5Grade= D — Weak
  6. 6Namespace Coverage= 71.9
  7. 7Policies Actually Enforcing= 55.3
  8. 8Exempted Namespace Share= 18.8
  9. 9Namespaces With No Policy= 18 namespaces

Assumptions and limits

  • The result is derived only from the 10 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Admission Controller Coverage calculated?

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.

Why does Admission Controller Coverage matter?

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.

What values do I need to enter?

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.

Is failurePolicy: Fail safe to use?

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.

Should policies start in audit mode?

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.

Related Calculators

Admission Controller Coverage Calculator | Calcrivo