Kubernetes admission control

Admission control for Kubernetes. Signed evidence for your auditor.

Decide which images run in your cluster and keep signed proof of every decision, inside the cluster it protects.

What it is

What is Attestkeep?

Attestkeep is container image security for Kubernetes, with the audit evidence built in. It scans every image for vulnerabilities with a database refreshed every 6 hours, verifies signatures, SBOMs and provenance, and admits or denies each pod at the door by your policy. Through Falco it watches what runs and can record, raise an issue or stop a pod. Every decision goes into a signed ledger, and from that ledger it builds evidence packages for 13 compliance frameworks that your auditor can verify without us. One Helm release, inside your cluster; nothing about your images leaves it.

See it in action
Your imagesfrom any registry
Your policya CRD, kept in Git
Falco eventsfrom your own Falco
Attestkeepone Helm release, inside the cluster
Admission webhookdecides at the door
Image scanningTrivy, database refreshed every 6 hours
Signatures and attestationscosign, SBOM, provenance
Runtime with Falcoevents to records, issues or a stopped pod
Decision ledgerevery allow and deny, signed
Evidence packages13 frameworks, each clause cited
Admitted podsallow or deny, with the reason
Your auditorevidence packages for 13 frameworks, verified without us
Your teame-mail, Slack, Teams, Jira, GitLab
Your Kubernetes cluster

Who is Attestkeep for?

Built for Kubernetes teams who have to prove what runs, not only run it.

Security leaders

Set the policy once. Prove it was enforced.

  • Policy as a CRD, kept in Git
  • Rules for known-exploited CVEs and end-of-life base images
  • A ledger of every allow and deny, with the policy that ran
  • Nothing leaves the cluster: no SaaS, no data upload

Developers and DevSecOps teams

One Helm release. Admission never waits on a scan.

  • One Helm release, inside your own cluster
  • Trivy scan, cosign signature and attestation checks at the door
  • What-if replay and break-glass before you enforce
  • Falco events turned into records, issues or a stopped pod

Auditors

Evidence in your format, verified without us.

  • Evidence packages for 13 frameworks, every clause cited
  • Signed by the cluster, verified in a browser without us
  • The policy revision and the verdict behind every record
  • A 52-page handbook with screenshots from a real installation
Vulnerabilities

Critical vulnerabilities the gate already knows.

Every six hours Attestkeep pulls the Trivy vulnerability database, the same one its scanner reads inside your cluster. These are the newest entries it rated critical, and when the gate knew.

See all critical vulnerabilities
From image to evidence

One chain, inside your cluster.

  1. ScanTrivy, inside the cluster
  2. Verify the signaturecosign, key or keyless
  3. Decide at admissionyour policy, on the cached verdict
  4. Recordevery allow and deny, in the ledger
  5. Sign the reportwith the installation's key
  6. Verify anywhereby your auditor, without us

See it refuse something.

Install Attestkeep in one Helm release and watch the gate decide. Every security feature is in the free edition.

Where are you starting from

Three places teams start from.

No admission control yetNothing checks an image before it runs.

One Helm release installs the operator, its console and its database into a namespace you own. Images are scanned with Trivy and their signatures checked with cosign, and admission refuses what your policy does not allow. Community Edition is free and does not expire.

Admission control
Passing an auditThe auditor wants proof, not screenshots.

Pick a framework and a period. Attestkeep maps the cluster's own admission and scan records to that framework's clauses and signs the report inside the cluster. Your auditor checks the signature with their own tools, without asking us.

Evidence packages
Running at scaleRules that hold when many teams deploy.

Policy is a Kubernetes resource your Argo CD or Flux can own. Accepted risks carry a reason and an expiry, break-glass is recorded, and a new critical finding opens a ticket in GitHub, GitLab or Jira. Sign-in goes through the identity provider you already run.

The product