Nous utilisons le même scanner.

Ce qu'est Trivy Operator

L'operator d'Aqua exécute Trivy en continu dans le cluster et y consigne ses résultats sous forme de custom resources : un VulnerabilityReport par workload, plus des audits de configuration, des évaluations RBAC, des recherches de secrets exposés et des SBOM. Il est gratuit, sous Apache-2.0, largement déployé et, à plusieurs égards, sa couverture paraît plus large que la nôtre : nous n'auditons pas le RBAC, nous ne cherchons pas de secrets dans les manifestes et nous ne faisons pas de benchmark de vos nodes.

Si votre question est « qu'est-ce qui ne va pas dans ce cluster ? », c'est une excellente réponse, et la vérifier ne coûte rien.

Un rapport n'arrête aucun pod

Un VulnerabilityReport est un enregistrement, pas une barrière. L'operator n'enregistre pas de webhook d'admission et ne refuse aucun déploiement, et c'est voulu : pour imposer quoi que ce soit, la méthode documentée consiste à placer un second outil devant (un moteur de policies qui lit ces rapports, ou un webhook que vous écrivez) et à accepter la condition de course qui va avec. Le rapport décrit un pod qui tourne déjà.

Attestkeep prend le problème par l'autre bout. L'admission consulte un verdict qui existe déjà pour ce digest d'image et répond dans la même requête ; elle n'attend jamais la fin d'un scan, et un pod dont l'image n'a jamais été scannée est un cas que la policy tranche, pas un angle mort. Le scan continue ensuite en arrière-plan : la base de vulnérabilités est mise à jour toutes les six heures, chaque image est rescannée chaque jour, et une nouvelle vulnérabilité critique sur une image déjà admise déclenche une notification et peut ouvrir un ticket dans votre propre GitHub, GitLab ou Jira.

La seconde différence tient à ce qui reste. Les rapports sont des ressources du cluster et changent avec lui ; quand le pod disparaît, son rapport disparaît aussi. Attestkeep écrit les verdicts dans un PostgreSQL que vous contrôlez, avec le hash de la policy qui a servi à les évaluer, et c'est à partir de cet historique qu'un rapport de période est ensuite construit.

Deux rapports de conformité différents

Les deux produits proposent un « rapport de conformité », mais ils ne répondent pas à la même question. Le ClusterComplianceReport de Trivy Operator couvre le CIS Kubernetes Benchmark, les recommandations de durcissement de la NSA et les Pod Security Standards : ce cluster est-il configuré comme le demande un guide de durcissement ?

Le nôtre ne porte pas sur la configuration. C'est un rapport sur une période (ce que l'admission a vu, admis, refusé, et pourquoi), rattaché à treize réglementations et jeux de contrôles comptant 293 exigences, chacune citée et dotée d'un statut : satisfaite, partielle, écart ou hors périmètre. Le quatrième statut est essentiel : un operator dédié aux containers peut étayer, au mieux, un tiers de l'article 21 de NIS2, et un rapport qui rattache en silence les deux autres tiers à sa propre liste de fonctionnalités est pire que l'absence de rapport. Le paquet est signé dans votre cluster et votre auditeur peut le vérifier sans nous.

Lequel vous faut-il

Trivy Operator seul suffit quand vous voulez de la visibilité et que vous acceptez d'agir à la main, ou quand le durcissement de la configuration du cluster est le travail qui vous attend. Il est gratuit et il le fait bien.

Attestkeep s'adresse aux cas où une vulnérabilité doit changer ce que fait le cluster, et où quelqu'un vous demandera plus tard de prouver que c'est bien arrivé. Si les deux comptent, les outils ne s'excluent pas : gardez l'operator pour le RBAC et les benchmarks de nodes, et laissez l'admission faire barrage. La Community Edition est gratuite pour toujours : la comparaison peut se faire sur votre cluster plutôt que sur cette page.