ansible-hardening-linux/CICD.md

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.