162 lines
9.3 KiB
Markdown
162 lines
9.3 KiB
Markdown
# CI/CD sécurisée — Gitea 1.22.6
|
|
|
|
La version du serveur `https://gitea.ops.xpeditis.com` a été vérifiée via
|
|
`/api/v1/version` : **1.22.6**. Les pipelines ciblent Gitea Actions / act_runner,
|
|
avec des jobs exécutés dans des conteneurs Linux AMD64.
|
|
|
|
## Workflows et contrôles
|
|
|
|
Les quatre workflows actifs se trouvent dans `.gitea/workflows/`. Les anciennes
|
|
copies `.github/workflows/` sont déplacées pour éviter une double exécution.
|
|
L'action composite `.gitea/actions/security` est appelée directement par chaque
|
|
pipeline ; aucun workflow réutilisable GitHub ni client `gh` n'est nécessaire.
|
|
|
|
| Pipeline | Déclenchement | Contrôles |
|
|
| --- | --- | --- |
|
|
| Dev CI | Push/PR vers `dev` | Lint, types, tests unitaires, sécurité |
|
|
| PR Checks | PR vers `preprod` ou `main` | Idem + tests d'intégration PostgreSQL/Redis |
|
|
| CD Preprod | Push vers `preprod` | Idem + build, scan AMD64/ARM64, déploiement, contrôles HTTP |
|
|
| CD Production | Push vers `main` | Qualité/tests/sécurité, provenance préprod, build frontend, scan AMD64, déploiement SSH, tests de fumée |
|
|
|
|
Le job **Security gate** exécute :
|
|
|
|
- `npm audit --package-lock-only --audit-level=high` sur la racine, le backend,
|
|
le frontend et le log-exporter, sans installer de dépendances ni exécuter leurs
|
|
scripts. Les dépendances de développement sont incluses.
|
|
- Trivy sur les fichiers suivis du commit : détection de secrets et de mauvaises
|
|
configurations Docker/Kubernetes/Terraform, seuil HIGH/CRITICAL.
|
|
- La validation statique des workflows et les tests des scripts de promotion/santé.
|
|
|
|
Les images sont analysées par digest, avec HIGH/CRITICAL bloquants, y compris
|
|
lorsqu'aucun correctif n'est disponible. Les erreurs de scanner ou de registre
|
|
échouent aussi : aucune exclusion générale ni échec masqué n'est ajouté.
|
|
Les installations applicatives utilisent `npm ci`, le runtime est Node 22 et les
|
|
actions sont épinglées par SHA. Trivy, Actionlint et Hetzner CLI sont téléchargés
|
|
avec vérification SHA256. Le lint backend ne réécrit plus les fichiers.
|
|
|
|
Les rapports sont joints aux exécutions **Gitea Actions** avec
|
|
`actions/upload-artifact` **v3**, compatible avec le protocole de cette version
|
|
Gitea. `security-reports` est conservé 7 jours, `image-security-*` 14 jours selon
|
|
la politique de rétention du serveur. Les valeurs et extraits de code des secrets
|
|
sont retirés du rapport téléchargeable. Les URLs GitHub servent uniquement à
|
|
récupérer les actions publiques épinglées, pas à exécuter les pipelines.
|
|
|
|
Ces scans ne remplacent pas un audit du code métier ni un test d'intrusion ; la
|
|
recherche de secrets porte sur le commit courant, pas tout l'historique.
|
|
|
|
## Promotion sans API GitHub
|
|
|
|
Gitea 1.22.6 n'expose pas d'API de consultation des runs Actions dans son Swagger.
|
|
La provenance utilise donc le registre Scaleway existant : après scans, webhooks
|
|
et contrôles HTTP backend/frontend réussis, le job préprod publie des marqueurs
|
|
`validated-preprod-<SHA complet>` pour le backend et le log-exporter, à partir des
|
|
digests construits et scannés. Le log-exporter est construit/scanné par cette
|
|
chaîne ; son déploiement n'a pas de webhook ni de contrôle HTTP dédié existant.
|
|
|
|
La production accepte seulement un commit de main ou un de ses parents dont
|
|
l'arbre Git est identique, avec les deux marqueurs présents. Elle récupère leurs
|
|
digests, les rescane et les promeut sans reconstruire le backend/log-exporter.
|
|
Le frontend est reconstruit avec les URLs prod puis scanné par digest. Les tags
|
|
`prod-SHA` et `latest` ne sont publiés que dans le job de déploiement, après scans.
|
|
|
|
Utiliser un merge classique ou fast-forward de préprod vers main ; un squash ou
|
|
rebase qui supprime cette provenance sera refusé. Il faut une première préprod
|
|
réussie avec ces nouveaux workflows avant de promouvoir en production. La preuve
|
|
repose sur les droits du registre : réserver l'écriture des marqueurs au compte CI
|
|
et ne pas les créer manuellement. Ce n'est pas une attestation cryptographique.
|
|
|
|
Les images candidates peuvent rester dans le registre après un échec de scan,
|
|
sans être publiées sous les alias d'environnement par le pipeline.
|
|
|
|
## Configuration nécessaire sur ton instance
|
|
|
|
Gitea 1.22 ignore notamment `concurrency`, `permissions`, `environment`, les délais
|
|
YAML de jobs et `workflow_dispatch`. Ces paramètres ne sont donc pas présentés
|
|
comme des protections effectives dans les workflows adaptés.
|
|
|
|
1. Activer Actions dans le dépôt et disposer d'un runner Docker Linux AMD64 avec
|
|
le label `ubuntu-latest`, Git, Bash, Python 3, curl, tar, timeout et les outils
|
|
Docker. Les builds multiarchitecture ont besoin du support QEMU/binfmt.
|
|
Les services d'intégration sont joints via `postgres` et `redis`, sans ports
|
|
hôte fixes ; un runner en mode host n'est pas la cible de ces workflows.
|
|
2. Enregistrer **un seul runner** avec le label **`xpeditis-deploy`**, une capacité
|
|
**1**, et une limite d'exécution adaptée (par exemple 1 h). Les deux jobs de
|
|
déploiement utilisent ce label : publication des alias, déploiement, santé et
|
|
fermeture du firewall restent dans le même job. Ne pas donner ce label à
|
|
plusieurs runners. Le runner doit être isolé des jobs de PR et disposer de
|
|
Docker, Git, curl, SSH et rsync. Sans ce runner, les déploiements restent en attente.
|
|
3. Protéger `dev`, `preprod`, `main` dans les réglages de branches Gitea : interdire
|
|
les push directs/force-push et exiger **Security gate**, les deux contrôles
|
|
qualité et les deux tests unitaires ; ajouter l'intégration pour preprod/main.
|
|
Choisir les noms exacts proposés après la première exécution. Les approbations
|
|
humaines doivent être imposées sur les PR, pas via `environment`.
|
|
4. Renseigner les secrets/variables dans **Settings → Actions** du dépôt Gitea :
|
|
registre, webhooks Portainer, URLs préprod, URLs de build et identifiants
|
|
SSH/Hetzner déjà référencés. Les secrets ne sont pas des secrets d'environnement
|
|
GitHub. Les clés SSH temporaires sont écrites dans le répertoire du job.
|
|
5. Les fonctions manuelles `workflow_dispatch` ne sont pas disponibles sur 1.22.
|
|
L'ancien workflow de rollback est conservé hors du dossier actif dans
|
|
`.gitea/manual/rollback.reference.yml` comme référence, sans prétendre qu'il est
|
|
exécutable sur cette version. Le rollback SSH automatique de production reste
|
|
actif en cas d'échec du déploiement ou des tests de fumée. Pour une intervention
|
|
manuelle, utiliser la procédure serveur existante ; ne pas ajouter un faux
|
|
bouton de lancement Gitea.
|
|
|
|
Ces réglages serveur/runners n'ont pas été modifiés depuis cette session. Aucun
|
|
pipeline distant ni déploiement n'a été lancé.
|
|
|
|
## Mises à jour de dépendances
|
|
|
|
Dependabot a été remplacé par `renovate.json`. La configuration propose des PR
|
|
vers `dev` pour npm, Docker et les actions, sans fusion automatique. Elle n'installe
|
|
ni ne démarre un bot. Un service Renovate doit être configuré séparément avec
|
|
`RENOVATE_PLATFORM=gitea`, `RENOVATE_ENDPOINT=https://gitea.ops.xpeditis.com/api/v1`,
|
|
un compte bot et son token, et le dépôt `David/xpeditis2.0`. Conserver le token hors
|
|
du dépôt. Les hashes des outils téléchargés dans les scripts doivent être mis à
|
|
jour en même temps que leurs versions.
|
|
|
|
## Alertes déjà constatées
|
|
|
|
Audits npm des lockfiles au 22 septembre 2026 :
|
|
|
|
| Projet | HIGH | CRITICAL |
|
|
| --- | ---: | ---: |
|
|
| Racine | 0 | 0 |
|
|
| Backend | 50 | 0 |
|
|
| Frontend | 13 | 1 |
|
|
| Log-exporter | 0 | 0 |
|
|
|
|
Ce sont des entrées de dépendances signalées, pas nécessairement autant de CVE
|
|
distinctes. L'entrée critique frontend concerne `next` ; npm propose une migration
|
|
majeure. Aucune mise à jour applicative forcée n'a été faite pour masquer ces résultats.
|
|
|
|
Le scan local des configurations a relevé 11 alertes Kubernetes HIGH : systèmes
|
|
de fichiers inscriptibles, droits de monitoring et accès hôte. Elles restent à
|
|
examiner et bloquantes. Certains accès peuvent être nécessaires au monitoring.
|
|
|
|
Les secrets Stripe en dur de la stack préprod ont été remplacés par les variables
|
|
Portainer obligatoires `STRIPE_SECRET_KEY` et `STRIPE_WEBHOOK_SECRET`. Renseigner
|
|
ces variables avant redéploiement. Si les anciennes valeurs sont actives, les
|
|
révoquer/renouveler dans Stripe : elles restent dans l'historique Git. Le scan de
|
|
ces configurations ne signale plus ce secret après modification.
|
|
|
|
## Validation
|
|
|
|
Les 19 tests offline de promotion et santé passent : arbre différent, marqueurs
|
|
manquants, panne du registre, digest invalide, mauvaise branche, saisie hostile et
|
|
échec HTTP sont refusés. Les tests vérifient aussi que les échecs et délais des
|
|
audits restent bloquants et que le rapport masque les valeurs de secrets. Actionlint valide la syntaxe après normalisation des URLs
|
|
d'actions Gitea ; ce contrôle ne remplace pas une exécution avec act_runner.
|
|
|
|
```bash
|
|
ACTIONLINT_BIN=/chemin/vers/actionlint bash scripts/ci/validate-workflows.sh
|
|
```
|
|
|
|
Les installations ont été vérifiées avec `npm ci --dry-run --offline
|
|
--ignore-scripts --legacy-peer-deps`. Les builds Docker, les tests applicatifs sous
|
|
Node 22, le transport réel des artefacts et les déploiements sont encore à valider
|
|
sur les runners de l'instance.
|
|
|
|
Références : [différences Gitea 1.22](https://docs.gitea.com/1.22/usage/actions/comparison/),
|
|
[Renovate sur Gitea](https://docs.renovatebot.com/modules/platform/gitea/).
|