Il dit qui a signé l'image. Pas ce qu'elle contient.

Ce qu'est policy-controller

Un admission controller du projet Sigstore. Une ClusterImagePolicy nomme les autorités auxquelles une image doit satisfaire (une clé publique, ou une identité keyless et son émetteur) et les attestations qu'elle doit porter ; un pod est admis quand chaque policy concernée compte au moins une autorité satisfaite. Il résout les tags en digests pour que ce qui tourne soit bien ce qui a été admis, l'application s'active namespace par namespace, et une policy CUE ou Rego peut s'appliquer au contenu d'une attestation une fois sa signature vérifiée.

Il est sous Apache-2.0, gratuit, léger, et maintenu par ceux qui définissent les formats de cosign. Pour un cluster dont la chaîne d'approvisionnement se résume à « tout ce que nous faisons tourner est signé par notre propre système de build », c'est une réponse complète et vous devriez l'utiliser.

Où ils se recoupent

Exactement sur la vérification des signatures et des attestations à l'admission. Attestkeep vérifie les signatures cosign avec une clé ou en keyless par rapport à une identité et un émetteur, contrôle les attestations in-toto et peut exiger qu'elles ne dépassent pas un âge maximal, exige un SBOM ou une déclaration de provenance vérifiés quand la policy le prévoit, et épingle les images par digest. Si c'est cette liste que vous cherchez, policy-controller le fait et ne coûte rien.

La jonction

Une signature dit que quelqu'un s'est porté garant de ces octets. Elle ne dit pas que ces octets sont sûrs. Une image signée ce matin par un système de build de confiance peut porter une vulnérabilité critique publiée cette nuit, et chaque policy du cluster l'admettra, à juste titre, parce que la signature est valide. Vérification et vulnérabilité sont deux questions différentes, et une seule est posée.

policy-controller n'a ni scanner, ni base de vulnérabilités, ni historique : il évalue la requête qu'il a devant lui et passe à la suivante. Attestkeep pose les deux questions dans un même verdict (la signature, et les vulnérabilités trouvées par Trivy sur le même digest, le catalogue CISA des vulnérabilités exploitées signalant celles qui sont attaquées), puis conserve la réponse. La base est mise à jour toutes les six heures et chaque image est rescannée chaque jour : une image saine à son admission ne reste pas saine par simple supposition.

Et la trace survit à la requête. Les verdicts sont écrits dans un PostgreSQL que vous contrôlez, avec le hash de la policy qui les a produits, et c'est ce qui rend un rapport de période possible : treize réglementations et jeux de contrôles, 293 exigences, chacune citée et dotée d'un statut (satisfaite, partielle, écart ou hors périmètre), le tout signé dans votre cluster et vérifiable par votre auditeur sans nous.

Lequel vous faut-il

policy-controller seul quand toutes les images que vous faites tourner sont construites et signées par vous, quand ce que vous devez imposer est la provenance plutôt que le contenu, et quand vous préférez rester aussi près du projet Sigstore qu'un déploiement le permet.

Attestkeep quand « signé » ne veut pas dire « sûr » dans votre modèle de menace (images de base venues d'ailleurs, images d'éditeurs, tout ce que vous n'avez pas construit vous-même), ou quand la vérification de signature doit constituer une preuve et pas seulement un comportement. Les deux tournent comme webhooks de validation et peuvent cohabiter dans un cluster, même si une règle d'image s'exprime mieux une seule fois, dans l'un des deux. La Community Edition est gratuite pour toujours : vous pouvez mettre notre outil à côté du vôtre avant de décider.