[infra] Faire confiance au CA local de Caddy pour l'envoi des artefacts SBOM en CI #77

New issue

Closed

opened 2026-09-02 09:41:29 +00:00 by gabriel · 0 comments

gabriel commented

2026-09-02 09:41:29 +00:00

Member

Exigence couverte

ENF-11

Épreuve servie

EC03 · CI/CD et qualité

Ce qu'on veut obtenir

Que l'envoi des trois artefacts SBOM (sbom-applicatif, sbom-outillage, sbom-dashboard) réussisse réellement en CI, sans dépendre d'un nom de domaine public ni d'un certificat ACME qu'on n'aura jamais d'ici la fin du projet. Aujourd'hui l'envoi échoue systématiquement (unable to get local issuer certificate contre le CA auto-signé de Caddy) et ne passe au vert que grâce à continue-on-error — l'inventaire ne quitte donc jamais réellement le runner.

Critères d'acceptation

Les trois étapes actions/upload-artifact (sbom-applicatif, sbom-outillage, sbom-dashboard) se terminent sans l'erreur unable to get local issuer certificate, sur une exécution complète de la chaîne.
La confiance dans le CA de Caddy est établie à l'exécution de chaque run (poignée de main TLS), aucun certificat ni empreinte n'est figé dans le dépôt — l'intermédiaire tourne chaque semaine, la feuille toutes les 12h.
Les trois artefacts sont téléchargeables depuis la page d'exécution après un passage vert de la chaîne.
docs/runbooks/ci.md documente la solution retenue et ne présente plus les deux options (HTTP local / certificat public) comme un choix encore ouvert.
continue-on-error: true reste présent sur les trois envois, comme garde-fou général, pas comme correctif du problème de certificat.

Comment on le vérifie

Fichier de test : tests/ci/test-confiance-caddy.sh
Commande : bash tests/ci/test-confiance-caddy.sh (rejoue la récupération de certificat en local contre l'adresse de la forge) puis relecture du journal d'une exécution réelle de dependances-python / dependances-dashboard.
Attendu : le script confirme au moins un certificat récupéré et écrit ; le journal de l'exécution réelle ne contient aucune ligne unable to get local issuer certificate, les 3 artefacts apparaissent en pièces jointes.

Manuel d'exploitation à mettre à jour

docs/runbooks/ci.md, section « Envoi des artefacts (SBOM) »

Risque et retour arrière

La récupération du certificat se fait sans vérification préalable (rejectUnauthorized: false le temps de la poignée de main) : première confiance sans empreinte pré-connue, risque jugé acceptable car limité au réseau interne du runner, qui joint déjà la forge en clair pour d'autres appels. Retour arrière : supprimer l'étape de récupération de CA, continue-on-error seul suffit à ne pas casser la chaîne, comme avant ce ticket.

### Exigence couverte ENF-11 ### Épreuve servie EC03 · CI/CD et qualité ### Ce qu'on veut obtenir Que l'envoi des trois artefacts SBOM (`sbom-applicatif`, `sbom-outillage`, `sbom-dashboard`) réussisse réellement en CI, sans dépendre d'un nom de domaine public ni d'un certificat ACME qu'on n'aura jamais d'ici la fin du projet. Aujourd'hui l'envoi échoue systématiquement (`unable to get local issuer certificate` contre le CA auto-signé de Caddy) et ne passe au vert que grâce à `continue-on-error` — l'inventaire ne quitte donc jamais réellement le runner. ### Critères d'acceptation - [x] Les trois étapes `actions/upload-artifact` (`sbom-applicatif`, `sbom-outillage`, `sbom-dashboard`) se terminent sans l'erreur `unable to get local issuer certificate`, sur une exécution complète de la chaîne. - [x] La confiance dans le CA de Caddy est établie à l'exécution de chaque run (poignée de main TLS), aucun certificat ni empreinte n'est figé dans le dépôt — l'intermédiaire tourne chaque semaine, la feuille toutes les 12h. - [x] Les trois artefacts sont téléchargeables depuis la page d'exécution après un passage vert de la chaîne. - [x] `docs/runbooks/ci.md` documente la solution retenue et ne présente plus les deux options (HTTP local / certificat public) comme un choix encore ouvert. - [x] `continue-on-error: true` reste présent sur les trois envois, comme garde-fou général, pas comme correctif du problème de certificat. ### Comment on le vérifie Fichier de test : `tests/ci/test-confiance-caddy.sh` Commande : `bash tests/ci/test-confiance-caddy.sh` (rejoue la récupération de certificat en local contre l'adresse de la forge) puis relecture du journal d'une exécution réelle de `dependances-python` / `dependances-dashboard`. Attendu : le script confirme au moins un certificat récupéré et écrit ; le journal de l'exécution réelle ne contient aucune ligne `unable to get local issuer certificate`, les 3 artefacts apparaissent en pièces jointes. ### Manuel d'exploitation à mettre à jour `docs/runbooks/ci.md`, section « Envoi des artefacts (SBOM) » ### Risque et retour arrière La récupération du certificat se fait sans vérification préalable (`rejectUnauthorized: false` le temps de la poignée de main) : première confiance sans empreinte pré-connue, risque jugé acceptable car limité au réseau interne du runner, qui joint déjà la forge en clair pour d'autres appels. Retour arrière : supprimer l'étape de récupération de CA, `continue-on-error` seul suffit à ne pas casser la chaîne, comme avant ce ticket.

gabriel added the

EC03

Kind/CICD

labels

2026-09-02 09:41:34 +00:00

gabriel added this to the EnerVision project

2026-09-02 09:42:39 +00:00

gabriel self-assigned this

2026-09-02 09:42:40 +00:00

gabriel referenced this issue from a commit

2026-09-02 09:46:26 +00:00

infra: fait confiance au CA local de Caddy pour l'envoi des artefacts SBOM