Admission control pour Kubernetes. Preuves signées pour votre auditeur.
Décidez quelles images tournent dans votre cluster, avec la preuve signée de chaque décision, dans le cluster lui-même.
Qu'est-ce qu'Attestkeep ?
Attestkeep, c'est la sécurité des container images pour Kubernetes, preuves d'audit comprises. Il scanne chaque image avec une base mise à jour toutes les 6 heures, vérifie signatures, SBOM et provenance, et admet ou refuse chaque pod à l'entrée selon votre policy. Via Falco, il surveille ce qui tourne et peut enregistrer, ouvrir une issue ou arrêter un pod. Chaque décision va dans un registre signé, d'où il produit des evidence packages pour 13 frameworks de conformité, vérifiables par votre auditeur sans nous. Un seul Helm release, dans votre cluster ; rien sur vos images n'en sort.
Le voir en actionÀ qui s'adresse Attestkeep ?
Pour les équipes Kubernetes qui doivent prouver ce qui tourne, pas seulement le faire tourner.
Responsables sécurité
Définir la policy une fois. Prouver qu'elle a été appliquée.
- La policy est une CRD, versionnée dans Git
- Règles pour les CVE exploitées et les images de base en fin de vie
- Un registre de chaque allow et deny, avec la policy appliquée
- Rien ne quitte le cluster : pas de SaaS, pas d'envoi de données
Développeurs et équipes DevSecOps
Un seul release Helm. L'admission n'attend jamais un scan.
- Un seul Helm release, dans votre propre cluster
- Scan Trivy, signature cosign et attestations vérifiés à l'entrée
- Rejeu what-if et break-glass avant d'appliquer
- Les événements Falco deviennent des enregistrements, des issues ou un pod arrêté
Auditeurs
Des preuves dans votre format, vérifiables sans nous.
- Des evidence packages pour 13 frameworks, chaque clause citée
- Signés par le cluster, vérifiables dans un navigateur, sans nous
- Derrière chaque enregistrement, la révision de policy et le verdict
- Un manuel de 52 pages, captures d'une vraie installation
Les vulnérabilités critiques que le gate connaît déjà.
Toutes les six heures, Attestkeep récupère la Trivy vulnerability database, celle que le scanner lit dans votre cluster. Les entrées critiques les plus récentes, et le moment où le gate l'a su.
Toutes les vulnérabilités critiquesCinq parties, une release Helm.
Admission control
Scanner, vérifier la signature, décider à l'entrée. L'admission lit un verdict mis en cache : elle n'attend jamais la fin d'un scan.
Admission controlPaquets de preuves
Un rapport de période rattaché à un framework, signé par votre cluster, vérifiable par tous.
Paquets de preuvesRuntime avec Falco
Falco voit, Attestkeep décide. Vos policies transforment les événements Falco en enregistrements, notifications, issues ou pods arrêtés.
Runtime avec FalcoSupply chain
Signatures, SBOM, provenance de build et déclarations des éditeurs, vérifiées avant qu'une image ne démarre.
Supply chainExploitation
Notifications, synchronisation des issues et clusters air-gapped : comment Attestkeep s'intègre à vos outils et réseaux.
ExploitationUne chaîne, dans votre cluster.
- ScannerTrivy, dans le cluster
- Vérifier la signaturecosign, par clé ou keyless
- Décider à l'admissionvotre policy, sur le verdict en cache
- Consignerchaque autorisation et chaque refus, dans le registre
- Signer le rapportavec la clé de l'installation
- Vérifier partoutpar votre auditeur, sans nous
Regardez-le refuser quelque chose.
Installez Attestkeep en un seul Helm release et regardez la porte décider. Toutes les fonctions de sécurité sont dans l'édition gratuite.
Trois points de départ.
Pas encore d'admission controlRien ne contrôle l'image avant qu'elle tourne.
Une seule release Helm installe l'operator, sa console et sa base de données dans un namespace qui vous appartient. Trivy scanne les images, cosign vérifie leurs signatures, et l'admission refuse ce que votre policy n'autorise pas. La Community Edition est gratuite et n'expire pas.
Admission controlUn audit à passerL'auditeur veut des preuves, pas des captures.
Choisissez un framework et une période. Attestkeep rapproche les enregistrements d'admission et de scan du cluster des exigences de ce framework, puis signe le rapport dans le cluster. Votre auditeur vérifie la signature avec ses propres outils, sans passer par nous.
Paquets de preuvesÀ grande échelleDes règles qui tiennent quand beaucoup d'équipes déploient.
La policy est une ressource Kubernetes que votre Argo CD ou Flux peut gérer. Un risque accepté porte une justification et une date d'expiration, le break-glass est enregistré, et une nouvelle vulnérabilité critique ouvre un ticket dans GitHub, GitLab ou Jira. La connexion passe par votre fournisseur d'identité habituel.
Le produitRien ici ne vous demande de nous croire sur parole.
Trois bons outils, et la jonction entre eux.
Chacun de ces outils fait bien une partie du travail et il est gratuit. Aucun ne réunit au même endroit un scanner, un vérificateur de signatures et l'enregistrement de la décision ; or c'est précisément ce qu'un auditeur demande.