# 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](../.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](../template) 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,
* Les fichiers de secrets sont injectés dans le conteneur via la directive `env_file`, sans l'extension `.example`.

Sur la machine où est clonée le dépôt :
* 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`),

## 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](https://github.com/arminc/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](https://cve.mitre.org/)). 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](https://github.com/docker/docker-bench-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](#formalisme-du-dpt)) 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`.