Le scan CI ne ferme pas la boucle
La plupart des équipes scannent déjà les images dans le pipeline. C’est nécessaire. Ce n’est pas suffisant.
Entre le build et le runtime, une image différente peut encore atteindre le cluster: un tag réutilisé, un déploiement manuel, un environnement qui saute la même porte, un registre secondaire. Si la seule barrière vit dans la CI, l’API server Kubernetes accepte encore tout Pod conforme au manifeste.
La question utile n’est pas de savoir si vous scannez. C’est quand vous pouvez refuser une image avec des preuves de vulnérabilités et une politique explicite.
Ce que décide vraiment l’admission control
Un ValidatingAdmissionWebhook s’exécute lorsque l’API server évalue create ou update. Si le webhook renvoie allowed: false, l’objet n’entre pas. Les opérateurs n’ont pas besoin de lire un rapport après coup.
Cela transforme la posture de vulnérabilités d’un rapport en décision opérationnelle: autoriser, avertir ou auditer selon des règles définies.
Ce que fait KATANA
KATANA est notre control plane open-source pour cette décision. Avant qu’un Pod n’atterrisse, il interroge un backend de scan configuré (JFrog Xray et/ou Amazon Inspector sur ECR), applique des politiques (deny, warn, audit), enregistre les détections et peut faire appliquer le résultat via le webhook natif Kubernetes.
En pratique:
- la politique vit dans SQLite ou dans des CRD
ImagePolicy - l’évaluateur dérive la sévérité et applique des exceptions de namespace si configuré
- le mode dry-run montre l’impact sans bloquer les déploiements
- il y a une UI par cluster et une vue de flotte avec métriques Prometheus entre environnements
L’API server reste le composant qui bloque. KATANA fournit l’évaluation et la preuve.
Pourquoi le dry-run compte
Activer l’enforcement dès le premier jour crée souvent une friction politique, pas un doute technique. Plateforme et produit doivent voir ce qui aurait été bloqué, avec quel message et sur quelle image, avant de durcir une règle.
Le dry-run transforme « cela cassera la production » en une liste concrète de findings et d’exceptions. Ensuite, deny est une décision documentée, pas une opinion.
Limites à énoncer
KATANA ne remplace pas le scanner. Il dépend de la qualité et de la couverture du backend (Xray, Inspector ou autres intégrations). Il ne résout pas non plus, à lui seul, la chaîne d’approvisionnement signée, la détection runtime ou la posture réseau.
Son rôle est étroit: au moment de l’admission, cette image respecte-t-elle la politique définie par l’organisation?
Comment nous l’utilisons avec les clients
Dans le travail DevSecOps et plateforme Kubernetes, nous partons de cette question. Nous évaluons ce qui est scanné aujourd’hui, ce qui atteint le cluster sans le même contrôle, et où une porte d’admission apporte plus qu’un autre rapport.
KATANA est notre propre tooling. Nous le mettons à disposition des clients lorsque le problème est de fermer l’écart entre scan et runtime.
Dépôt: github.com/zpol/katana. Pour revoir l’admission d’images sur votre plateforme, planifiez une réunion ou consultez DevSecOps & Automation.