Attestkeep

Container image security for Kubernetes: scan, verify signatures, decide at admission, and keep the evidence that it happened.

Attestkeep runs entirely inside your cluster. It scans the images your workloads use, verifies their signatures and attestations, and answers the API server at admission time — allow or deny, according to a policy you wrote. Every decision is recorded, and those records are what an auditor is actually asking for.

What it is made of

Admission is cache-first

Scanning takes minutes; the API server waits seconds. So the two are never in the same path. The scanner fills a cache in the background and the webhook reads it, which is why a slow registry cannot slow down a deployment.

The consequence worth understanding before you install: a digest nobody has seen before has no scan result yet. What happens to it is a policy decision you make, and the default is to admit it and scan it immediately rather than block a deployment on a cold cache.

Nothing is fetched from outside your installation

Trivy and Cosign are built into the image rather than downloaded at install time. The console loads no fonts, scripts or analytics from anywhere. The vulnerability database comes from whichever registry you point it at — by default a public one, and in an air-gapped cluster your own mirror.

The single exception is licensing, and it is deliberately narrow: one endpoint, once a day, carrying three values. See Licensing for exactly what leaves the cluster and what happens when it cannot.

You can build the gate for free — the question is the record

Be clear-eyed about this, because your platform team will ask: admission policy engines and in-cluster scanners exist as excellent open source, and if what you need is "block :latest and fail critical CVEs", you can assemble that without us. What that assembly does not give you is the part auditors and incident reviews actually consume:

• A decision record with integrity. Every admission decision here is content-hashed at write time and sealed under signed, chained checkpoints — flip one verdict in the database and the next evidence document names the exact record. A stack of controller logs cannot make that claim. See the evidence trust model.
• Decisions tied to the policy that made them. Each record carries the hash of the policy as it stood at that moment — "what rule was in force when this was admitted" is a lookup, not an archaeology project through git history and deploy timestamps.
• Honest gaps. Windows where the webhook was down or unverifiable are recorded and printed in the evidence, and the reconciliation sweep names what got in during them. A control that cannot testify about its own outages is a control your auditor discounts.
• One surface. Scan results, signature verification, admission, exceptions with expiry and justification, and the evidence package that ties them together — maintained as one product, not as glue code your team owns forever.

If none of that is on your requirements list, use the free tools — genuinely. The moment someone asks you to prove what your gate did and when, this is the product.

Where to go next

• Install — one Helm command, and the one value worth setting on the first run.
• What runs in your cluster — the full inventory: workloads, RBAC, every outbound connection.
• Licensing — plans, cluster slots, the daily check, and what happens offline.
• Admission — how a decision is made, and the two settings that change your posture.
• Prove it is enforcing — the five-minute check that the gate is really standing.
• Air-gapped clusters — mirroring the database and what signature verification means without a transparency log.