0.17.0 — Vérification sur une vraie infrastructure

0.17.0 — 2026-10-15 — Vérification sur une vraie infrastructure

Les fichiers générés sont exécutés pour de vrai sur les machines de GitHub Actions (onze scénarios, chaque nuit) ; ces passages ont trouvé une dizaine de défauts, corrigés ci-dessous. Le déploiement réel sur un cloud (apply puis destroy) attend un compte de test et viendra dans une 0.17.x.

Ajouté
Tests de bout en bout (tools/e2e/run.py, workflow « Bout en bout ») : les fichiers générés exécutés pour de vrai sur les machines de GitHub Actions. Trois scénarios pour commencer : chart Helm avec CloudNativePG dans kind, overlays Kustomize avec PostgreSQL et Valkey dans kind, hôte Docker avec Compose, sauvegarde puis restauration. Une application de démonstration (tools/e2e/app) ne répond 200 sur /db que si chaque base accepte une connexion authentifiée avec les secrets transmis par le pipeline.
Second palier : OpenBao initialisé et configuré par les scripts générés puis lu par External Secrets (kind-coffre-openbao) ; Keycloak par son opérateur derrière Traefik, realm appliqué par OpenTofu puis relu sans écart, revendication groups vérifiée (kind-identite-keycloak). Preuves publiées en annotations.
Ajouté (suite)
Zabbix pris en charge sur hôte Docker et VM : images officielles 7.4 (serveur, interface web, agent 2) et base PostgreSQL dédiée, mot de passe par le circuit habituel (variables CI, SOPS ou coffre), interface derrière Traefik, section du mode d'emploi (mot de passe Admin à changer par l'API, agent vérifié). Keycloak, Dex et Zabbix apparaissent dans la vue Ports, et R39 signale leur conflit sur 8080 sans Traefik.
Fiches Puppet, Chef Infra, Elasticsearch, Kibana, Logstash, ZAP, Burp Suite DAST, CircleCI et Drone CI, au niveau « à configurer à la main » : dans la palette et contrôlées par les règles (rôle déjà tenu, licence, cycle de vie). Leurs entrées du CNCF Landscape mènent à la fiche. Règle R51 : Drone CI, repris par Harness, avec remplacement par Woodpecker.
Bases de Zabbix et de Keycloak sur l'hôte Docker sauvegardées et restaurées par db-backup.sh et db-restore.sh, comme celles de l'application.
Scénarios de bout en bout compose-sops (clé age, brique, secrets-seed.sh, puis les lignes mêmes de la CI générée) et sauvegarde-restauration de Zabbix.
ZAP pris en charge (DAST) : un job après le déploiement de l'environnement analysé (par défaut le dernier avant la production), avant le déploiement suivant, dans chaque CI générée. Scan de base (passif), complet ou d'API (OpenAPI) ; image officielle à version fixe (2.17.0) ; adresse analysée réglable par environnement ; .zap/rules.tsv généré (règles d'en-têtes et de cookies à FAIL) ; rapport HTML et JSON publié même en échec ; non bloquant par défaut, paramètre « Bloquant ». Section « Analyse dynamique » du mode d'emploi. Scénario de bout en bout compose-zap : le job extrait du workflow généré analyse l'application derrière Traefik, en root comme sur GitHub Actions et sous l'utilisateur de l'image comme sur GitLab CI.
Dimensionnement des machines : besoin de chaque hôte Docker calculé à partir des services du fichier Compose généré (application, bases, Traefik, Keycloak, Zabbix, SonarQube, Prometheus, Grafana…), multiplié par les environnements qu'il porte ; section « Dimensionnement » de PIPELINE.md ; pour les machines créées par Terraform, type retenu comparé au besoin et plus petit type suffisant proposé sur chacun des six clouds. Règle R52 (machine sous-dimensionnée) avec correction en un clic, par environnement quand les machines diffèrent. Valeurs par service dans data/sizing.yaml, sourcées quand une documentation les donne (Keycloak, Grafana, SonarQube), estimées sinon.
Scénarios de bout en bout kind-argocd (dépôt GitOps privé sur Gitea, Argo CD installé par platform/install.sh et branché par le mode d'emploi, job de déploiement de la CI joué dans alpine comme sur GitLab : l'étiquette poussée arrive dans le cluster, une relance sans changement ne casse rien) et compose-dex (découverte OpenID, connexion de l'application suivie jusqu'à la page d'autorisation de la forge, adresse de retour inconnue refusée). Un scénario seul se lance à la demande (entrée scenario du workflow).
Paramètre « Dépôt GitOps » des briques Argo CD et Flux, repris dans les applications, la source Flux et la variable GITOPS_REPO ; mode d'emploi Argo CD sans la CLI argocd (secret de dépôt étiqueté, attente de la synchronisation), jeton de lecture saisi sans écho.
Corrigé
GitOps (Argo CD, Flux) ne pouvait pas fonctionner tel que généré : le dépôt surveillé était une adresse d'exemple codée en dur ; la CI ne changeait que l'étiquette de l'image, si bien que le dépôt restait ghcr.io/OWNER/… (Helm) ou $CI_REGISTRY_IMAGE que Kustomize ne développe pas ; apk add yq est ambigu sur Alpine 3.20 (yq-go maintenant) ; un pipeline relancé échouait sur un commit vide ; avec le dépôt de l'application comme dépôt GitOps, chaque mise à jour relançait le pipeline (commits marqués [skip ci]). La source Flux reçoit le secret d'accès créé par le mode d'emploi.
Dex sur hôte Docker démarrait sans application OAuth : Compose remplaçait $DEX_CONNECTOR_ID et $DEX_CONNECTOR_SECRET de sa configuration par l'environnement du shell au déploiement, vide sur l'hôte, et DEX_CONNECTOR_ID n'était écrit nulle part. Les deux sont désormais lus par Dex dans secrets/dex.env. Le premier passage du scénario compose-dex réussissait parce que le harnais transmettait les secrets à docker compose up : il ne transmet plus que IMAGE, comme le déploiement par SSH.
Étapes non bloquantes (Checkov, KICS, Snyk, Infracost, Floci) : Tekton, AWS CodeBuild et Google Cloud Build arrêtaient le pipeline à leur échec ; elles sont maintenant tolérées (onError: continue, allowFailure, échec signalé dans le journal de CodeBuild).
Binaire sops non vérifié : la CI générée téléchargeait sops et l'exécutait, clé age en mémoire, sans contrôle ; son empreinte publiée est maintenant vérifiée (sha256sum -c) avant exécution.
Traefik sur hôte Docker ne faisait pas de HTTPS : aucune configuration TLS, le port 443 répondait en HTTP clair. TLS sur l'entrée websecure, certificat Let's Encrypt (challenge TLS), redirection du port 80, volume des certificats ; adresse ACME facultative (paramètre « Contact Let's Encrypt »). Trouvé en préparant les tests de bout en bout de l'hôte Docker.
Validation installée par pipx : les outils ajoutés à l'environnement de l'application (pipx inject devops-builder shellcheck-py) sont trouvés, alors qu'ils restaient « absents » ; le conseil d'installation propose pipx inject sous pipx ; un contrôle sans outil liste les fichiers générés qui le demandent (signalé lors du premier essai sur macOS).
Python 3.15 refusé à l'installation avec un message clair (requires-python), au lieu d'un échec de PySide6, dont les versions 6.11 ne vont pas au-delà de Python 3.14 (vu lors de l'installation sur macOS).
PySide6 limité aux 6.11 pour toutes les versions de Python : la 6.12.0 provoque aussi des erreurs de segmentation intermittentes sous Python 3.12 (vu sur la CI), pas seulement le plantage de sortie sous 3.11.
Keycloak sur Kubernetes ne démarrait pas, deux défauts trouvés par les tests de bout en bout : platform/install.sh n'installait pas les CRD keycloakoidcclients et keycloaksamlclients de l'opérateur 26.8, qui ne devenait jamais disponible ; et l'image officielle, désignée dans la ressource Keycloak, était lancée avec --optimized et s'arrêtait en boucle (startOptimized: false ajouté).