guide_developpeur_ci.md



Explications et améliorations de la CI
Cette section répertorie des détails un peu plus poussés sur le fonctionnement de la chaîne d'intégration, qui viendraient parasiter le guide de fonctionnement normal.
Tout est configuré dans le fichier .gitlab-ci.yml. Sa lecture est sans doute un peu cryptique pour certaines parties, on pourra consulter la documentation de Gitlab pour l'explication des différentes directives.

Formalisme du dépôt
Pour que la CI fonctionne correctement, il faut respecter plusieurs contraintes. Il ne s'agit pas de bonnes pratiques, mais de conventions (discutables).
On peut utiliser le template fourni pour partir sur une bonne base.

Chaque service géré par la chaîne d'intégration a son dossier pica-* ou meta-*,
Chaque dossier contient au moins un Dockerfile, un docker-compose.yml et un clair-whitelist.yml,
Le nom final de l'image est spécifiée dans le docker-compose.yml, au format registry.picasoft.net/nom:version, et le nom doit correspondre au dossier,
Les secrets sont répertoriés dans des fichiers *.secrets.example dans un sous-dossier secrets, avec des valeurs d'exemple,
Le dossier secrets doit avoir comme permissions 770 et les fichiers à l'intérieur de ce dossier 660. Tous les dossiers et fichiers de ce dépôt doivent avoir pour groupe docker (gid: 999),
Les fichiers de secrets sont injectés dans le conteneur via la directive env_file, sans l'extension .example.


Des analyses de sécurité ?
Les analyses de sécurité permettent d'auditer les images Docker que nous construisons, afin de prévenir un maximum de failles de sécurité sur nos services. En effet, bien que les conteneurs Docker soient en théorie isolés du système lui-même, ils contiennent des données critiques. Il faut donc s'assurer que l'image est suffisamment propre avant de la lancer, d'autant qu'on se base parfois sur des images pré-construites.
Les analyses sont de deux types : statique ou dynamique.
L'analyse statique est effectuée par Clair Scanner : son objectif est d'analyser l'intégralité des paquets installés dans une image Docker et de reporter les vulnérabilités présentes sur ces paquets (CVE, ou Common Vulnerabilities and Exposures). Cette analyse ne dit rien sur la sécurité du service en lui-même, mais plutôt sur la sécurité des bibliothèques dont il dépend.
Cette analyse n'échoue que lorsque des CVE de niveau High ou plus sont détectées. Le fichier clair-whitelist.yml sert justement à autoriser certaines CVE de niveau High à contourner cette restriction, après une analyse qui aurait déterminé qu'elle n'affecte pas la sécurité de notre service.
L'analyse dynamique est effectuée par Docker Bench for Security, qui lance le service en interne et vérifie que le ou les conteneurs lancés respectent une liste de bonnes pratiques. Docker Bench for Security ne fait jamais échouer la CI, même lorsque les bonnes pratiques ne sont pas respectées, car ce n'est pas toujours possible. Il faut néanmoins tendre vers le respect de ces bonnes pratiques. En pratique, nous utilisons très peu cette étape et sa pertinence devra être discutée.

Étapes manuelles ou automatiques ?
Le push sur le registre de production est toujours manuel, car il faut s'assurer au préalable que le service a été testé par un humain avant de le pousser.
La mise à jour d'un Dockerfile entraîne le lancement de l'ensemble de la CI.
La mise à jour d'une liste blanche de CVE (voir Formalisme du dépôt) déclenche uniquement l'analyse de sécurité statique sur la dernière image construite (pas de nécessité de reconstruire l'image).
La mise à jour d'un docker-compose.yml déclenchait l'analyse de sécurité dynamique sur la dernière image construite (pas de nécessité de reconstruire l'image) : à présent, elle n'est déclenchée que manuellement.
La mise à jour d'un fichier autre donne la possibilité de déclencher manuellement les étapes de la CI : on appréciera au cas par cas s'il est nécessaire de reconstruire l'image. Par exemple, mettre à jour le README ou un fichier de secrets d'exemple ne devrait pas déclencher la CI, tandis que mettre à jour un fichier de configuration devrait déclencher la CI.

Meta-images
On prévoit à terme d'utiliser ce dépôt pour construire aussi les images qu'il utilise lui même. Pour l'instant, c'est en test avec meta-registry-test pour construire l'image utilisée par le registry docker sur pica01-test.