Nein, es ersetzt Kyverno nicht.

Was Kyverno ist

Kyverno ist die Policy-Engine für Kubernetes, und das ist keine Höflichkeitsfloskel: Die CNCF hat das Projekt am 16. März 2026 in den Status graduated aufgenommen, die Stufe von Kubernetes, Prometheus, Envoy und Helm. Kyverno validiert, verändert, erzeugt und bereinigt Ressourcen jeder Art; seine Policies sind Kubernetes-Ressourcen statt einer eigenen Sprache, die man erst lernen muss; und es steht unter Apache-2.0, eine Lizenz muss niemand kaufen.

Kyverno prüft auch Container-Images. Die verifyImages-Regeln und die neuere ImageValidatingPolicy prüfen cosign-Signaturen und Attestations – mit Public Key oder keyless gegen Identität und Issuer – und lehnen einen Pod ab, dessen Image nicht mitbringt, was die Policy verlangt. Das ist echte Image-Sicherheit, und sie ist kostenlos. Wer etwas anderes behauptet, will Ihnen etwas verkaufen.

Wo sie sich decken

Bei einer Regel: Ist dieses Image von jemandem signiert, dem wir vertrauen? Beide Projekte beantworten die Frage bei der Admission, beide nutzen die Formate von cosign, beide arbeiten mit einem Schlüssel oder einer keyless Identität. Wenn Sie nur Signaturprüfung brauchen, erledigt Kyverno das bereits, und dafür brauchen Sie uns nicht.

Die Nahtstelle

Eine Policy-Engine bewertet die Anfrage, die ihr vorliegt. Sie kann eine Attestation lesen, die jemand anderes erzeugt hat, und deren Inhalt auswerten. Doch die Attestation erzeugen, eine Schwachstellendatenbank aktuell halten, ein vor drei Wochen zugelassenes Image neu scannen, weil gestern eine CVE veröffentlicht wurde, und die Historie aller Urteile aufbewahren, damit sich über einen Zeitraum berichten lässt – nichts davon ist Aufgabe einer Policy-Engine, und Kyverno erhebt diesen Anspruch auch nicht.

Diese Lücke füllen Teams mit einem zweiten Werkzeug und einer Pipeline dazwischen: Ein Scanner schreibt Berichte, eine Engine liest sie, und irgendwo macht eine Tabelle aus beidem etwas, das ein Auditor akzeptiert. Attestkeep schließt diese Lücke in einem Release: Scanner, Signaturprüfung, Urteilsspeicher und Bericht sind ein Programm, deshalb kann der Eintrag über eine Entscheidung nicht von der Entscheidung abweichen.

Was Attestkeep fehlt, ist der Rest von Kyverno. Es schreibt keine Labels, erzeugt keine Ressourcen, erzwingt nichts zu Replicas, Limits, Namespaces oder Network Policies und betreibt überhaupt keinen Mutating Webhook. Jenseits des Images hat es keine Meinung.

Beide betreiben

Beide sind auf Koexistenz ausgelegt. Attestkeep registriert ausschließlich validierende Webhooks – keinen mutierenden, also gibt es keine Reihenfolgefrage bei der Admission – und beschränkt sich auf die Namespaces, die Sie ihm zuweisen. Kyverno macht weiter alles, was es bisher getan hat, und die sinnvolle Aufteilung legen schon die Namen nahe: Kyverno ist für die Form Ihrer Ressourcen zuständig, Attestkeep für den Inhalt des Images und den Eintrag darüber, warum es zugelassen wurde.

Wenn Sie eine Image-Regel bereits in Kyverno formulieren, lassen Sie sie dort oder verlagern Sie sie hierher, aber nicht beides. Lehnen zwei Engines denselben Pod ab, entstehen zwei verschiedene Meldungen für eine Ablehnung, und wer Bereitschaft hat, liest nur die erste.

Was Sie brauchen

Kyverno allein ist die richtige Wahl, wenn Policies über den ganzen Cluster das Problem sind, wenn Signaturprüfung so weit in die Image-Sicherheit reicht, wie Sie gehen müssen, oder wenn Scanner und Nachweisprozess bereits anderswo existieren und funktionieren.

Attestkeep dazu lohnt sich, sobald jemand eine Frage stellt, die eine Policy-Engine aus der vorliegenden Anfrage nicht beantworten kann: Was lief im letzten Quartal, was haben wir abgelehnt und warum, welcher dieser Befunde wird tatsächlich ausgenutzt, und wo ist der signierte Eintrag, der das belegt? Das Nachweispaket ist diese Antwort. Die Community Edition ist dauerhaft kostenlos, Sie können beide also im eigenen Cluster nebeneinander betreiben, bevor Sie etwas entscheiden.