Questions fréquentes

Il scanne les images que votre cluster exécute à la recherche de vulnérabilités, vérifie leurs signatures et leurs attestations, décide de ce que le webhook d'admission accepte et tient un journal d'audit de chaque décision, exception et break-glass. L'operator, son API, sa console et sa base de données s'installent dans un namespace qui vous appartient.

Ce n'est pas un capteur runtime. Il n'observe pas lui-même les syscalls, les flux réseau ni les arbres de processus d'un container en cours d'exécution ; si vous installez Falco, c'est Falco qui le fait, et les policies runtime d'Attestkeep décident de la suite donnée à ses événements. Ce n'est pas non plus un outil de posture cloud : il ne lit ni votre compte chez le fournisseur cloud ni vos politiques IAM.

Ce qu'il fait est plus étroit et démontrable : il décide de ce qui a le droit de démarrer, et il garde la trace de ce qu'il a décidé.

Pour la sécurité des images, il recoupe ces outils et va plus loin : ces moteurs savent exprimer « deny the :latest tag », mais n'ont derrière la règle ni scanner, ni cache CVE, ni vérificateur de signatures. Attestkeep réunit les trois et applique les règles liées aux images à partir du stockage de verdicts que ses scans alimentent.

Pour tout le reste de ce que fait un moteur de policies (labels, limites de ressources, conventions de namespace), ils restent le bon outil, et les deux tournent côte à côte sans conflit. Une réponse plus détaillée se trouve sur la page qui met Kyverno et Attestkeep côte à côte, avec le même exercice pour Trivy Operator et Sigstore policy-controller.

Pas dans cette release. Chaque cluster exécute son propre operator avec sa propre base et sa propre console, et ces installations sont indépendantes par conception : c'est justement pour cela que rien n'a à franchir la frontière d'un cluster. Une vue de flotte qui résume plusieurs installations sur une seule page est sur la roadmap, sans date ; nous préférons le dire plutôt qu'annoncer une release que nous pourrions manquer.

L'operator lui-même, oui : l'image de release est construite et signée pour les deux. Les verdicts de scan sont toutefois enregistrés pour linux/amd64 à ce jour ; sur une image multi-architecture, le résultat décrit donc l'image amd64 de l'index, et non la variante qu'exécutera un node arm64. Des verdicts par plateforme sont prévus.

Toute distribution conforme à partir de la 1.27, services managés, k3s et OpenShift compris. L'operator utilise des webhooks d'admission et des CRD standard ; il ne demande ni agent sur les nodes, ni DaemonSet privilégié, ni module noyau.

Trois valeurs, une fois par jour, pour la licence : l'identifiant de licence, une empreinte du cluster et la version de l'operator. Rien d'autre, et rien qui décrive ce que vous exécutez : aucun nom d'image, aucun résultat de scan, aucun identifiant CVE, aucun nom de workload ou de namespace, aucune topologie de cluster, aucun compte utilisateur, rien de votre base de données.

Ce n'est pas que nous choisissions de ne pas les envoyer : aucun chemin ne les transporterait. Les limites que votre plan fixe aux images, aux frameworks et aux nodes sont comptées et appliquées par l'operator dans votre propre cluster, et ces chiffres n'ont aucune raison d'en sortir. Nous ne détenons aucune copie de vos résultats, de vos noms d'image ni de la forme de votre cluster, et une console de sécurité qui a besoin de la liste de toutes vos images est précisément ce que ce produit est conçu pour ne pas être.

Pourquoi le contrôle quotidien existe, et ce qui se passe quand il échoue, est expliqué sur la page des licences.

Aucune. Le contrôle de licence quotidien n'est pas de l'analytics et n'en tient pas lieu : il transporte les trois valeurs ci-dessus et renvoie un verdict, et rien dans ce qu'il contient ne décrit votre usage du produit. Personne chez nous ne peut savoir combien d'images vous avez scannées, quels frameworks vous avez ouverts ou si quelqu'un s'est connecté cette semaine.

Le site n'en a pas non plus (ni script d'analytics, ni tag manager, ni contenu tiers intégré), et c'est pourquoi la politique cookies a si peu de choses à vous demander.

Dans une base PostgreSQL que vous contrôlez, dans votre propre namespace ou sur votre propre serveur. Exportez-la, sauvegardez-la ou supprimez le namespace : nous ne pouvons pas la lire et n'en détenons aucune copie.

Le nom de l'installation, la référence de l'image et le verdict ; jamais un nom de node, une adresse interne ou un endpoint. Les notifications partent vers les canaux que vous configurez (Slack, Teams, e-mail, webhook), et nulle part ailleurs.

Oui. Le scanner et le vérificateur de signatures sont figés dans l'image de release, vous répliquez la base de vulnérabilités dans votre propre registry, et le mapping de conformité est livré dans l'operator : une installation déconnectée produit donc les mêmes rapports qu'une installation connectée.

La licence était autrefois la partie qui exigeait une route vers l'extérieur. Elle passe désormais par un certificat que vous apportez. La console génère une petite demande d'activation qui désigne ce cluster (l'empreinte, la clé publique de l'operator, le nom du cluster et la version) ; vous la déposez sur votre page de licence, après avoir accepté les conditions d'activation hors ligne s'il s'agit d'une licence Enterprise, et le certificat qui vous revient est émis pour ce seul cluster. Il est valable jusqu'à la fin de la période payée plus trente jours, douze mois sur une licence sans date de fin, et vous prévient trente jours avant d'expirer. Tant que l'installation en détient un, elle ne fait aucun appel de licence.

L'activation hors ligne est disponible sur les licences Enterprise annuelles à partir du quinzième jour après l'achat, et sur toute licence annuelle ouverte dans le cadre d'un contrat avec nous. Les étapes sont décrites dans le guide d'installation. Un cluster qui dispose d'une route vers l'extérieur garde la voie la plus simple : une clé d'activation et le contrôle quotidien.

Le chart Helm apporte son propre PostgreSQL, ou prend le DSN d'une base que vous exploitez déjà. Si vous le pointez vers une base existante, le chart ne crée ni base ni volume claim pour elle ; le seul claim restant est le cache de la base de vulnérabilités du scanner. Dans les deux cas, l'operator crée et migre ses propres tables au premier démarrage : aucun SQL à lancer, aucune étape de migration à oublier lors d'une mise à jour.

Par défaut, la failure policy du webhook est Ignore : si l'operator ne peut pas répondre, les déploiements continuent sans protection plutôt que de s'arrêter. C'est le réglage sûr pour un cluster qui doit rester en service. Toute édition, Community comprise, peut passer en Fail et refuser tout ce qui n'a pas encore été scanné : un compromis délibéré, assumé explicitement.

L'admission est répliquée et répartie sur les nodes. Le travail périodique (scans, contrôles de licence, rétention) n'est assuré que par une seule réplique à la fois, grâce à un advisory lock PostgreSQL : une seconde réplique ne duplique jamais un scan ni une notification.

L'operator. La paire de clés est générée et renouvelée dans le cluster, et chaque réplique adopte la nouvelle sans redémarrage. Pas de dépendance à cert-manager, pas de rappel annuel dans votre agenda.

La mise à jour se fait avec helm upgrade ; les migrations embarquées appliquent les nouvelles étapes et ignorent les autres. La désinstallation, c'est helm uninstall puis la suppression du namespace. Le webhook disparaît avec la release : un operator désinstallé ne laisse donc jamais derrière lui une admission bloquante.

Vous créez un compte sur attestkeep.com, choisissez un plan et d'éventuelles options, et recevez une clé. Vous saisissez cette clé dans votre propre console, et l'activation l'échange contre un certificat signé qui indique ce que vous avez acheté, le cluster pour lequel il a été émis et sa date de fin. La Community Edition fonctionne de la même façon ; son certificat n'a simplement pas de date d'expiration.

Ensuite, à chaque démarrage, l'operator vérifie le certificat sans quitter le cluster : notre signature, l'expiration, et si l'empreinte qu'il contient est bien celle de ce cluster. Séparément, une fois par jour, il vérifie la licence auprès de nous. Le certificat vaut trente jours ; un échec du contrôle quotidien ne change donc rien pendant longtemps. Tout est détaillé sur la page des licences.

L'installation repasse en Community Edition. Elle ne s'arrête pas, ne vous bloque pas et ne se met pas à refuser les déploiements : le scan et l'admission continuent dans les limites gratuites. Un contrôle de sécurité qui se désactive à cause d'une date de facturation est un pire résultat qu'une facture impayée.

Un certificat qui expire parce que le serveur de licences est resté injoignable un mois se comporte de la même façon, et c'est annoncé bien avant : la console prévient après une semaine sans route et les administrateurs reçoivent un e-mail avant l'expiration du certificat.

Il n'y a pas d'essai limité dans le temps, et c'est voulu : la Community Edition comprend toutes les fonctions de sécurité et n'expire pas. Elle fait le travail d'un essai, sur votre propre cluster, aussi longtemps que vous le souhaitez. Les plans payants ajoutent de la capacité, et le single sign-on, pas des fonctions de sécurité. Quand une licence payante expire sans renouvellement, l'installation repasse en Community Edition au lieu de couper quoi que ce soit.

Les paiements sont encaissés par Polar Software, Inc., notre marchand officiel (merchant of record), qui vous revend la licence : la facture est émise par Polar, la taxe due à votre adresse de facturation est calculée et perçue au checkout de Polar, et aucun numéro de carte ne nous parvient. La licence et le support sont les nôtres. Une entreprise de l'UE immatriculée à la TVA l'acquitte elle-même par autoliquidation.

Oui, jusqu'au nombre que paie votre plan : c'est exactement ce que désigne le nombre de clusters sur la grille tarifaire. Community et Team en comprennent 1, Business 3, Enterprise 5. La même clé active chacun d'eux et chaque activation consomme un slot ; votre compte montre quels clusters occupent des slots et combien sont libres.

Au-delà, l'activation suivante est refusée plutôt qu'autorisée en silence. Vous pouvez libérer un slot inutilisé, ou ajouter des clusters à la clé que vous possédez sans toucher aux installations en cours.

Pas pour la facturation : il n'y a ni comptage à l'usage ni facture qui varie avec l'utilisation. Chaque plan fixe un plafond de nodes par cluster : Community 1, Team 6, Business 10, Enterprise 20. Les nodes supplémentaires s'achètent à l'unité, jusqu'à 50 nodes par cluster au checkout.

L'operator compte les nodes Ready dans le cluster, et le chiffre n'est envoyé nulle part ; le contrôle de licence quotidien transporte les trois mêmes valeurs qu'auparavant. Au-dessus du plafond, rien ne s'arrête : la console et une notification le signalent, avec une échéance à 14 jours. Passé ces 14 jours, seuls les noms d'images pas encore vus sur la période sont refusés, et tout ce qui a déjà été compté continue de tourner. Revenir sous le plafond remet le compteur à zéro.

Rien ne change pendant dix jours à un mois, selon la durée de validité qui restait au certificat au moment de la coupure. Les contrôles échoués sont retentés quelques heures plus tard plutôt que le lendemain : une panne doit donc durer des semaines avant de devenir un problème de licence, et la console prévient dès la première semaine au lieu de vous laisser le découvrir plus tard.

Être injoignable et être refusé, ce n'est pas pareil : le silence consomme la durée restante du certificat, tandis qu'une réponse indiquant que la licence a été libérée ou révoquée s'applique aussitôt.

Réinstaller l'operator est gratuit : l'empreinte est dérivée du cluster, pas de l'operator. Le supprimer et le redéployer ne demande donc rien de notre part, et le certificat continue de fonctionner.

Reconstruire le cluster crée une nouvelle empreinte, donc un nouveau cluster du point de vue de la licence, qui prend un slot. Si l'ancien cluster existe encore, désactivez-le d'abord : le slot est libéré immédiatement. S'il a déjà disparu, libérez son slot depuis votre compte ; la liste indique chaque cluster qui en occupe un et sa date d'activation, pour que vous puissiez les distinguer.

13 instruments aujourd'hui : le Cyber Resilience Act (règlement (UE) 2024/2847) avec NIS2 à ses côtés, DORA, les Trust Services Criteria de SOC 2, NIST SP 800-190, le SSDF (SP 800-218), une sélection de contrôles SP 800-53 Rev. 5, l'annexe A de l'ISO/IEC 27001:2022, l'article 32 du RGPD, les exigences 6 et 11 de PCI DSS v4.0.1, les MAS Technology Risk Management Guidelines (janvier 2021), l'ASD Essential Eight Maturity Model (novembre 2023), les Control Criteria d'ISMAP (août 2024) et les critères de certification ISMS-P (novembre 2023).

Le mapping est livré dans l'operator au lieu d'être téléchargé : un cluster dont la seule route vers l'extérieur est l'endpoint de licence produit donc le même document qu'un cluster entièrement connecté. Chaque exigence porte sa propre citation et l'évaluation qui la fonde ; une exigence à laquelle un cluster ne peut pas répondre est marquée hors périmètre, avec la raison, car un paquet de preuves qui en revendique trop vaut moins qu'un paquet qui reconnaît ses limites.

L'édition gratuite inclut 1 framework de votre choix ; les plans payants en comprennent davantage.

Non, et le document le dit. Ce sont des preuves tirées de vos propres enregistrements, et aucun auditeur n'est tenu de les accepter. Ce qu'il supprime, c'est l'étape du tableur : qui a accepté quel risque, quand et pour combien de temps, tout cela est déjà consigné.

met (satisfaite), partial (partielle), gap (écart) et outside_scope (hors périmètre). Un rapport qui ne connaît que « réussi » ou « échoué » oblige chaque contrôle à mentir ; outside_scope indique qu'un contrôle ne s'applique pas à un admission controller Kubernetes, ce qui est une réponse défendable, et différente d'un échec. Si le webhook est resté quarante minutes hors service un mardi, cette fenêtre figure dans le document.

Dans le tracker d'issues public, github.com/attestkeep/attestkeep-docs. Les signalements de toutes les éditions y sont traités publiquement, y compris ceux de la Community Edition : l'offre gratuite est à l'origine de la plupart des premiers signalements, et les clore en privé serait un gâchis.

Pas dans une issue publique. Utilisez la voie d'advisory privée décrite sur la page sécurité ; vous recevrez un accusé de réception sous trois jours ouvrés. Les problèmes corrigés sont publiés sous forme d'advisories sur le même dépôt dès qu'une release contenant le correctif est sortie.

La Community Edition est prise en charge via le tracker d'issues public, où sont aussi traités les bugs des éditions payantes : les signalements ne sont pas triés selon ce que vous payez. Les plans payants ajoutent le support par e-mail et, à partir de Business, vos e-mails passent avant la file d'attente.

Nous ne publions de garantie de délai de réponse pour aucun plan. Un chiffre sur cette page serait une promesse faite à tout le monde à la fois par une équipe qui ne l'a convenue avec personne en particulier ; nous préférons répondre vite plutôt qu'écrire un chiffre qu'il faudrait défendre lors d'une mauvaise semaine.