← Tous les projets

Livraison continue · DevSecOps

Aucune image en ligne sans analyse

Le même pipeline GitLab CI pour chaque application du lab : construire sans privilège, analyser, promouvoir, déployer, vérifier. Une vulnérabilité corrigeable bloque la mise en ligne.

  • GitLab CI
  • Kaniko
  • Trivy
  • gitleaks
  • kubectl
  • RBAC

Le problème

Une image peut partir en ligne avec une vulnérabilité connue, et un compte de déploiement trop puissant est une porte ouverte sur tout le cluster.

Ce que j'ai construit

  • Branche, merge request, pipeline obligatoire : la fusion est bloquée tant que le pipeline n'a pas réussi.
  • Build avec Kaniko dans un pod du runner Kubernetes, sans accès privilégié ; l'image est publiée sous le tag du commit.
  • Trivy bloque la suite sur une vulnérabilité HIGH ou CRITICAL corrigeable. Le tag :latest n'est posé qu'après l'analyse.
  • Déploiement par kubectl set image, attente du déploiement progressif, puis test de fumée sur le site public. Pour l'application de démonstration, la version servie doit être celle du commit.
  • gitleaks parcourt tout l'historique Git à chaque pipeline : un secret commité, même supprimé ensuite, le fait échouer.

Choix et raisons

  • Le compte de service de la CI ne peut changer que l'image d'un Deployment nommé : aucun droit d'administration du cluster.
  • Une exception Trivy porte sa raison et une date d'expiration : passé cette date, le scan échoue de nouveau et la décision doit être reprise.
  • maxUnavailable à 0 : un nouveau pod doit être prêt avant qu'un ancien s'arrête, le site reste disponible pendant la mise à jour.

Vérifié

  • Premier scan : trois vulnérabilités HIGH dans une dépendance Python (starlette), corrigées avant d'activer le blocage.
  • L'image kubectl des déploiements est passée de 26 vulnérabilités HIGH corrigeables à quelques identifiants sans correctif publié, acceptés pour une durée limitée.
  • Ce site passe par ce même pipeline : Next.js exporté en statique, image nginx sans privilège, analysée avant d'être déployée.

Limites et suite

Les images ne sont pas encore signées, et le cluster ne vérifie rien à l'admission (signature, registre autorisé). C'est la suite prévue : SBOM, signature cosign, politiques Kyverno, déploiement canari avec retour arrière automatique. Seul le dépôt de l'application de démonstration est public.