start

CICD.md

@@ -0,0 +1,66 @@
+# CI/CD — dépôt `ansible-hardening-linux`
+
+Même principe qu'`ansible-centreon` : Gitea **contrôle** le code, Semaphore **l'exécute**.
+Une différence : Semaphore ne suit pas `main` mais la branche **`valide`**, qui n'avance
+que depuis `main` et seulement après un contrôle réussi. Un commit qui casse le lint
+n'atteint donc jamais Semaphore.
+
+```
+push / PR sur main ──► controle : yamllint, syntax-check, ansible-lint, clés présentes
+                              │ succès (push sur main uniquement)
+                              ▼
+                       promouvoir : main ──► valide
+                              │
+                              ▼
+            Semaphore (dépôt sur branche « valide ») exécute site.yml
+```
+
+## Contrôle du code — Gitea Actions
+
+`.gitea/workflows/ansible-lint.yml`, job `controle`, sur chaque pull request et chaque
+push vers `main` :
+
+| Étape | Ce qu'elle attrape |
+|---|---|
+| `yamllint .` | indentation, lignes trop longues, valeurs booléennes douteuses |
+| `ansible-playbook site.yml --syntax-check` + `--list-tasks` | playbook ou rôle cassé, tâche mal formée, variable manquante dans les rôles |
+| `ansible-lint` | mauvaises pratiques, modules dépréciés, tâches sans `changed_when` — profil `production` |
+| clés présentes | un répertoire `files/keys/<compte>/` sans fichier `.pub` verrouillerait ce compte |
+
+`vault.yml` étant chiffré, le syntax-check utilise `vault.yml.example` à sa place si le
+mot de passe n'est pas disponible dans la CI (il ne l'est pas, volontairement).
+
+## Promotion — job `promouvoir`
+
+Sur un push validé sur `main`, le job pousse le même commit sur `valide`. Il lui faut :
+
+- un secret de dépôt **`GITEA_TOKEN_PROMOTION`** : jeton d'un compte (de préférence un
+  compte technique) autorisé à écrire sur `valide` ;
+- la branche `valide` **protégée** dans Gitea, avec ce seul compte en liste blanche de
+  push, pour qu'aucun humain ne puisse y pousser directement.
+
+## Exécution — Semaphore
+
+À créer une fois dans le projet Semaphore :
+
+- **Dépôt** : l'URL Gitea de `ansible-hardening-linux`, branche **`valide`**.
+- **Clé SSH** : la clé privée du compte de connexion (`ansible` avec sudo, ou `root`
+  comme sur les VM Terraform). Sa clé publique doit figurer dans
+  `files/keys/<compte>/` — c'est ce que vérifie le rôle `ssh` avant de durcir.
+- **Mot de passe du vault** : entrée dédiée du magasin de clés, pointée par le modèle
+  de tâche, ou `ANSIBLE_VAULT_PASSWORD_FILE` dans l'environnement du modèle.
+- **Inventaire** : `inventory/hosts.yml` du dépôt (versionné), ou un inventaire
+  Semaphore si les hôtes changent souvent.
+- **Modèle `Simulation`** : `site.yml` avec `--check --diff` — à utiliser pour tout
+  premier passage sur un hôte.
+- **Modèle `Configuration`** : `site.yml`.
+- **Modèle `SSH seul`** : `site.yml --tags ssh`, pratique pour la rotation des clés.
+
+Semaphore installe les collections de `collections/requirements.yml` avant chaque exécution.
+
+## Secrets
+
+Rien de secret ne transite par Gitea : les communautés SNMP et les mots de passe SNMPv3
+sont dans `group_vars/all/vault.yml`, chiffré, et seul Semaphore détient le mot de passe
+du vault. Les clés publiques SSH et les certificats racine sont versionnés en clair :
+ce sont des éléments publics.