No, it does not replace Kyverno.

What Kyverno is

Kyverno is the Kubernetes policy engine, and calling it that is not a courtesy: the CNCF moved it to graduated status on 16 March 2026, the tier that holds Kubernetes, Prometheus, Envoy and Helm. It validates, mutates, generates and cleans up resources of any kind, its policies are Kubernetes resources rather than a language you have to learn first, and it is Apache-2.0 with no licence to buy.

It also verifies container images. Its verifyImages rules and the newer ImageValidatingPolicy check cosign signatures and attestations — with a public key or keylessly against an identity and issuer — and refuse a pod whose image does not carry what the policy demands. This is real image security and it is free. Anybody who tells you otherwise is selling something.

Where they overlap

On one rule: is this image signed by someone we trust. Both projects answer it at admission, both use cosign's formats, both can work from a key or from a keyless identity. If signature verification is the whole of what you need, Kyverno already does it and you do not need us for it.

Where the seam is

A policy engine evaluates the request in front of it. It can read an attestation that somebody else produced and reason about what is inside — but producing that attestation, keeping a vulnerability database current, rescanning an image that was admitted three weeks ago because a CVE was published yesterday, and holding the history of every verdict so that a period can be reported on: none of that is a policy engine's job, and Kyverno does not claim it.

That is the seam teams fill with a second tool and a pipeline between them — a scanner writing reports, an engine reading them, and a spreadsheet somewhere turning both into something an auditor will accept. Attestkeep is that seam as one release: the scanner, the signature verifier, the verdict store and the report are the same program, so the record of a decision cannot drift from the decision.

What Attestkeep does not have is the rest of Kyverno. It writes no labels, generates no resources, enforces nothing about replicas, limits, namespaces or network policy, and runs no mutating webhook at all. Outside the image, it has no opinion.

Running both

They coexist by design. Attestkeep registers validating webhooks only — no mutating webhook, so there is no admission ordering problem to think about — and it scopes itself to the namespaces you point it at. Kyverno keeps everything it was already doing, and the sensible division is the one the names suggest: Kyverno owns the shape of your resources, Attestkeep owns what is inside the image and the record of why it was let in.

If you already express an image rule in Kyverno, keep it there or move it here, but not both. Two engines denying the same pod produce two different messages for one refusal, and whoever is on call reads only the first one.

Which one you need

Kyverno alone is the right answer when policy across the whole cluster is the problem, when signature verification is as far into image security as you need to go, or when a scanner and an evidence process already exist somewhere else and work.

Attestkeep as well starts to pay when somebody asks a question a policy engine cannot answer from the request in front of it: what was running last quarter, what did we deny and why, which of these findings is actually exploited, and where is the signed record that says so. The evidence package is that answer, and Community Edition is free forever, so you can put the two side by side on your own cluster before deciding anything.