No, no sustituye a Kyverno.

Qué es Kyverno

Kyverno es el motor de policies de Kubernetes, y llamarlo así no es una cortesía: la CNCF le dio el estado graduated el 16 de marzo de 2026, el nivel de Kubernetes, Prometheus, Envoy y Helm. Valida, modifica, genera y limpia recursos de cualquier tipo; sus policies son recursos de Kubernetes, no un lenguaje que haya que aprender primero; y es Apache-2.0, sin licencia que comprar.

También verifica images de container. Sus reglas verifyImages y la más reciente ImageValidatingPolicy comprueban firmas y attestations de cosign, con clave pública o en modo keyless contra una identidad y un emisor, y rechazan el pod cuya image no lleve lo que exige la policy. Es seguridad de images de verdad, y gratuita. Quien le diga lo contrario le está vendiendo algo.

Dónde se solapan

En una regla: ¿está firmada esta image por alguien de confianza? Los dos proyectos la responden en la admission, los dos usan los formatos de cosign y los dos pueden trabajar con una clave o con una identidad keyless. Si la verificación de firmas es todo lo que necesita, Kyverno ya la hace y para eso no nos necesita.

Dónde está el hueco

Un motor de policies evalúa la petición que tiene delante. Puede leer una attestation que ha producido otro y razonar sobre su contenido. Pero producir esa attestation, mantener al día una base de datos de vulnerabilidades, volver a escanear una image admitida hace tres semanas porque ayer se publicó una CVE y conservar el historial de cada veredicto para poder informar sobre un periodo no es trabajo de un motor de policies, y Kyverno no dice que lo sea.

Ese es el hueco que los equipos cubren con una segunda herramienta y un pipeline entre ambas: un escáner que escribe informes, un motor que los lee y, en algún sitio, una hoja de cálculo que convierte las dos cosas en algo que un auditor acepte. Attestkeep cubre ese hueco en un solo release: el escáner, el verificador de firmas, el almacén de veredictos y el informe son el mismo programa, así que el registro de una decisión no puede apartarse de la decisión.

Lo que Attestkeep no tiene es el resto de Kyverno. No escribe labels, no genera recursos, no impone nada sobre réplicas, límites, namespaces o network policies, y no ejecuta ningún webhook de mutación. Fuera de la image, no opina.

Usar los dos

Están pensados para convivir. Attestkeep solo registra webhooks de validación, ninguno de mutación, así que no hay que preocuparse por el orden de la admission, y se limita a los namespaces que usted le indique. Kyverno sigue haciendo todo lo que ya hacía, y el reparto sensato es el que sugieren los nombres: Kyverno se ocupa de la forma de sus recursos, y Attestkeep, de lo que hay dentro de la image y del registro de por qué se dejó entrar.

Si ya expresa una regla de image en Kyverno, déjela allí o muévala aquí, pero no las dos cosas. Dos motores que rechazan el mismo pod producen dos mensajes distintos para un solo rechazo, y quien está de guardia solo lee el primero.

Cuál necesita

Solo Kyverno es la respuesta correcta cuando el problema es la policy de todo el cluster, cuando en seguridad de images le basta con verificar firmas, o cuando ya tiene en otro sitio un escáner y un proceso de evidencia que funcionan.

Attestkeep además empieza a compensar cuando alguien hace una pregunta que un motor de policies no puede responder con la petición que tiene delante: qué se ejecutaba el trimestre pasado, qué rechazamos y por qué, cuáles de estos hallazgos se están explotando de verdad y dónde está el registro firmado que lo demuestra. El paquete de evidencia es esa respuesta, y Community Edition es gratis para siempre, así que puede probar los dos lado a lado en su propio cluster antes de decidir nada.