Prove it is enforcing

An admission webhook that is silently not running looks exactly like a compliant cluster. This runbook takes five minutes, uses nothing but kubectl, and ends with you having seen a denial with your own eyes — run it after install, after upgrades, and any time trust needs re-earning.

1. Throw a bad pod at it

The default policy blocks the :latest tag, so the simplest possible violation is:

kubectl run enforcement-check --image=nginx:latest

Expected — the API server itself refuses, quoting the webhook:

Error from server: admission webhook "image-security.attestkeep.com" denied the request:
image security policy: nginx:latest: the :latest tag is blocked by policy

Two things worth noticing in that line. The error comes from Error from server — the deny happened inside the API server's admission chain, not in some agent that might have been sleeping. And the reason names the policy rule, so a developer reading it in a CI log knows what to fix without filing a ticket.

If the pod was created instead, enforcement is not working for you — go to step 4.

2. Confirm nothing was created

kubectl get pod enforcement-check

Expected: NotFound. A denial at admission means the object never existed — there is no half-created workload to clean up.

3. Check the decision was recorded

Open the console: the dashboard's Recently blocked admissions panel now leads with this denial, same reason string. If you prefer the surface your monitoring uses, the metrics tell the same story: attestkeep_admission_decisions_total{decision="denied"} has moved.

This step matters as much as the first: a denial that left no record would be enforcement without evidence, and half this product's point is that every decision has a record with a hash behind it.

4. If the pod went through

In order of likelihood:

• The namespace is bypassed. The webhook skips kube-system, cert-manager, its own namespace, and any namespace labelled attestkeep.com/webhook=bypass. Run the check from a normal workload namespace.
• The policy does not block what you threw. kubectl get isp default -o yaml — check enforcement: Enforce and blockLatestTag: true. An Audit policy records instead of denying, by design.
• The webhook is failing open. With the default failurePolicy: Ignore, an unreachable webhook admits silently. Check attestkeep_webhook_distrusted (it should be 0) and pod readiness in the attestkeep namespace. Any such window is written to the outage record and surfaces in the next evidence document — see Operations.
• The install is not activated. Every installation is licensed, the free edition included — and until a key is entered, nothing is enforced and every admission response says so in a warning. An activated free-edition install enforces exactly like a paid one.

What this does not prove

One denial proves the gate is standing, not that your policy is right. It says nothing about whether your thresholds match your risk appetite, whether signature requirements are on for the registries that matter, or what happened during past outage windows — those live in Policies and in your evidence documents. But it is the check that catches the failure mode that matters most: everything looking green while nothing is being checked at all.