Dice quién firmó la image. No qué contiene.

Qué es policy-controller

Un admission controller del proyecto Sigstore. Una ClusterImagePolicy nombra las autoridades que debe satisfacer una image (una clave pública, o una identidad keyless con su emisor) y las attestations que debe llevar; un pod se admite cuando cada policy que le aplica tiene al menos una autoridad que se cumple. Resuelve los tags a digests para que lo que se ejecuta sea lo que se admitió, el enforcement se activa por namespace, y se puede aplicar una policy CUE o Rego al contenido de una attestation una vez verificada su firma.

Es Apache-2.0, gratuito y pequeño, y lo mantienen quienes definen los formatos de cosign. Para un cluster cuya historia de supply chain se resume en «todo lo que ejecutamos lo firma nuestro propio sistema de build», es una respuesta completa y debería usarlo.

Dónde se solapan

De lleno en la verificación de firmas y attestations en la admission. Attestkeep verifica firmas cosign con clave o en modo keyless contra una identidad y un emisor, comprueba attestations in-toto y puede exigir que no superen una antigüedad máxima, exige un SBOM o una declaración de provenance verificados donde lo indique la policy, y fija las images por digest. Si esa lista es lo que busca, policy-controller ya lo hace y no cuesta nada.

Dónde está el hueco

Una firma dice que alguien responde por estos bytes. No dice que esos bytes sean seguros. Una image firmada esta mañana por un sistema de build de confianza puede llevar una vulnerabilidad crítica publicada anoche, y todas las policies del cluster la admitirán, con razón, porque la firma es válida. Verificación y vulnerabilidad son preguntas distintas, y solo se está haciendo una de ellas.

policy-controller no tiene escáner, no mantiene base de datos de vulnerabilidades y no guarda historial: evalúa la petición que tiene delante y pasa a la siguiente. Attestkeep responde a las dos preguntas con un mismo veredicto (la firma y los hallazgos de Trivy sobre el mismo digest, con el catálogo de vulnerabilidades explotadas conocidas de CISA marcando las que están siendo atacadas) y después guarda la respuesta. La base se actualiza cada seis horas y cada image se vuelve a escanear a diario, así que una image que estaba limpia al admitirse no se da por limpia para siempre.

Y el registro sobrevive a la petición. Los veredictos se escriben en un PostgreSQL que usted controla, bajo el hash de la policy que los produjo, y eso es lo que hace posible un informe del periodo: 13 frameworks, 293 requisitos, cada uno con su cita y marcado como cumplido, parcial, carencia o fuera de alcance, firmado dentro de su cluster y verificable por su auditor sin nosotros.

Cuál necesita

Solo policy-controller cuando todas las images que ejecuta las construye y firma usted, cuando lo que necesita imponer es la provenance y no el contenido, y cuando prefiere estar tan cerca del proyecto Sigstore como lo permita un despliegue.

Attestkeep cuando en su modelo de amenazas «firmado» no es lo mismo que «seguro» —images base de terceros, images de fabricantes, todo lo que no haya construido usted— o cuando la comprobación de la firma tiene que ser evidencia y no solo un comportamiento. Los dos funcionan como validating webhooks y pueden convivir en un cluster, aunque una regla de image se expresa mejor una sola vez, en uno de ellos. Community Edition es gratis para siempre, así que puede poner el nuestro junto al suyo antes de decidir.