Daniel Allaire
b775b7f99d
Suppression de toute trace Chezlepro de l'outil (roles, scripts, docs publiques, exemples, LICENSE). Prouve par scan exhaustif : git grep vide pour chezlepro, asgard/TrueNAS, supernet reel 10.1.x. Corrige 5 defauts de genericite fonctionnels (motd, app.ini Forgejo, organisation openldap, nom AC step-ca, et IP reelles codees en dur dans les defaults de roles -> plage d'exemple 10.0.x). LICENSE -> Alliance Boreale. Fichiers mainteneur + CHANGELOG conserves (par decision). La separation moteur/instance tient : OPS-Chezlepro surcharge deja ses vraies valeurs de topologie. Verifie : make verifier exit 0 (4 tests). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
312 lines
12 KiB
Markdown
312 lines
12 KiB
Markdown
# Golden template Debian 13 Proxmox
|
|
|
|
## Objet
|
|
|
|
Ce document justifie les ajouts appliqués par Set-OPS à une installation Debian 13 minimale pour obtenir le golden template Proxmox.
|
|
|
|
Le template doit rester un socle commun, clonable et sécuritaire. Il ne doit pas devenir un serveur applicatif ni intégrer des dépendances propres à un rôle final.
|
|
|
|
## État de départ
|
|
|
|
L'état de départ attendu est décrit dans :
|
|
|
|
```text
|
|
docs/procedure-template-debian13-proxmox.md
|
|
```
|
|
|
|
Résumé :
|
|
|
|
```text
|
|
Debian 13 minimal
|
|
aucun environnement graphique
|
|
SSH installé
|
|
partition EFI
|
|
partition racine ext4
|
|
pas de LVM
|
|
pas de swap
|
|
disque agrandissable
|
|
CloudInit Drive Proxmox présent
|
|
ciuser et clé SSH injectés par Cloud-Init
|
|
aucun secret
|
|
aucune donnée propre à un clone final
|
|
```
|
|
|
|
## Runbook du playbook prepare
|
|
|
|
### Objectif
|
|
|
|
Le playbook `debian13_proxmox_preparer.yml` transforme une VM Debian 13 minimale en socle golden template.
|
|
|
|
Il installe les composants communs, configure l'accès Ansible, applique le durcissement template-safe et prépare la VM pour cloud-init.
|
|
|
|
Il ne fait pas le nettoyage final avant conversion en template.
|
|
|
|
### Prérequis côté VM
|
|
|
|
Avant de lancer le playbook, la VM doit respecter ces conditions :
|
|
|
|
```text
|
|
Debian installé et démarré
|
|
réseau fonctionnel
|
|
SSH joignable depuis le poste Ansible
|
|
CloudInit Drive présent côté Proxmox
|
|
utilisateur Ansible initial injecté par Cloud-Init
|
|
clé publique SSH injectée par Cloud-Init
|
|
sudo ou accès root possible
|
|
APT fonctionnel
|
|
aucun rôle applicatif déjà installé
|
|
VM destinée à devenir un template, pas un serveur de production
|
|
```
|
|
|
|
Vérifications utiles depuis le poste Ansible :
|
|
|
|
```bash
|
|
ssh ansible@10.0.2.99
|
|
ansible -i instance/inventories/lab/hosts.yml modeles_vm -m ping
|
|
ansible -i instance/inventories/lab/hosts.yml modeles_vm -m setup
|
|
```
|
|
|
|
Adapter l'utilisateur et l'adresse IP selon `instance/inventories/lab/hosts.yml`.
|
|
|
|
### Prérequis côté dépôt
|
|
|
|
Avant l'exécution :
|
|
|
|
```bash
|
|
git status --short
|
|
make syntax-template
|
|
```
|
|
|
|
L'inventaire doit contenir la VM dans le groupe :
|
|
|
|
```text
|
|
modeles_vm
|
|
```
|
|
|
|
Les variables du template sont dans :
|
|
|
|
```text
|
|
instance/inventories/lab/group_vars/modeles_vm.yml
|
|
```
|
|
|
|
### Commande de préparation
|
|
|
|
Lancement lorsque l'accès par clé et sudo sont fonctionnels :
|
|
|
|
```bash
|
|
make preparer-modele
|
|
```
|
|
|
|
Le flux `make` suppose que SSH par clé et sudo NOPASSWD sont déjà fonctionnels pour `ansible`.
|
|
|
|
### Déroulement attendu
|
|
|
|
Le playbook :
|
|
|
|
1. vérifie que la cible est Debian ;
|
|
2. avertit si la version majeure n'est pas Debian 13 ;
|
|
3. installe les paquets communs ;
|
|
4. active `qemu-guest-agent` ;
|
|
5. installe et configure `cloud-init` ;
|
|
6. configure le compte technique Ansible ;
|
|
7. active la synchronisation du temps ;
|
|
8. configure SSH ;
|
|
9. applique le durcissement template-safe ;
|
|
10. prépare nftables sans l'activer ;
|
|
11. affiche le statut cloud-init.
|
|
|
|
### Résultat attendu
|
|
|
|
Une première exécution peut changer la VM.
|
|
|
|
Une relance sur une VM déjà préparée doit idéalement finir avec :
|
|
|
|
```text
|
|
failed=0
|
|
changed=0
|
|
```
|
|
|
|
Un résultat `changed=0` à la relance est le signal que le playbook est idempotent dans l'état actuel.
|
|
|
|
### Erreurs fréquentes
|
|
|
|
| Symptôme | Cause probable | Action |
|
|
| --- | --- | --- |
|
|
| `UNREACHABLE` | IP, SSH, utilisateur ou clé SSH incorrecte. | Vérifier `instance/inventories/lab/hosts.yml`, cloud-init et tester `ssh`. |
|
|
| échec `become` | Sudo NOPASSWD absent ou utilisateur non autorisé. | Corriger l'accès sudo initial, puis relancer `make preparer-modele`. |
|
|
| échec APT | DNS, passerelle, miroir Debian ou verrou APT. | Vérifier réseau, DNS et processus APT en cours. |
|
|
| erreur handler SSH | Handler manquant ou nom `notify` incohérent. | Vérifier les handlers du rôle SSH avant de relancer. |
|
|
| avertissement Debian non 13 | La cible n'est pas Debian 13. | Ne pas convertir en template Debian 13 sans justification. |
|
|
|
|
### Point d'arrêt
|
|
|
|
Après `prepare`, ne pas convertir immédiatement la VM en template.
|
|
|
|
Exécuter d'abord :
|
|
|
|
```bash
|
|
make verifier-modele
|
|
```
|
|
|
|
Le playbook de vérification contrôle notamment Debian 13, les paquets requis, l'absence de swap actif, l'absence d'environnement graphique, les services de base, `nftables` désactivé, sudo NOPASSWD et le durcissement SSH effectif.
|
|
|
|
Le nettoyage final se lance seulement après validation complète :
|
|
|
|
```bash
|
|
make nettoyer-modele CONFIRMER=true
|
|
```
|
|
|
|
Ne pas lancer le cleanup final sur une VM encore en diagnostic ou sur un serveur final.
|
|
|
|
## Préparation Ansible
|
|
|
|
Le playbook applique les rôles suivants :
|
|
|
|
```text
|
|
common_packages
|
|
qemu_guest_agent
|
|
cloud_init
|
|
sudo_ansible
|
|
chrony
|
|
ssh_baseline
|
|
systemd_ssh_auto
|
|
motd
|
|
hardening_packages
|
|
sysctl_durcissement
|
|
core_dumps
|
|
unattended_upgrades
|
|
apparmor
|
|
auditd
|
|
fail2ban_ssh
|
|
journald
|
|
ssh_durcissement
|
|
nftables_socle
|
|
```
|
|
|
|
## Justification des ajouts
|
|
|
|
| Rôle | Ajout ou changement | Justification | Limite volontaire |
|
|
| --- | --- | --- | --- |
|
|
| `common_packages` | Installe les outils système et diagnostic de base. | Permet l'administration locale, le dépannage réseau, l'exécution fiable d'Ansible et les opérations de maintenance courantes. | Aucun service applicatif spécialisé n'est installé. |
|
|
| `qemu_guest_agent` | Installe et active `qemu-guest-agent`. | Donne à Proxmox une visibilité propre sur l'état de la VM et facilite les opérations d'arrêt, IP reporting et gestion depuis l'hyperviseur. | Ne remplace pas la supervision applicative. |
|
|
| `cloud_init` | Installe `cloud-init` et `cloud-guest-utils`, puis active les services cloud-init. | Donne au clone son identité initiale : hostname, utilisateur, clé SSH, IP, DNS et agrandissement de disque. | Cloud-init ne sert pas à configurer les applications. |
|
|
| `sudo_ansible` | Crée ou maintient le compte technique et son sudo NOPASSWD. | Permet l'administration automatisée par Ansible sans stocker de mot de passe dans le dépôt. | Ce compte doit rester technique et contrôlé. |
|
|
| `chrony` | Installe et active la synchronisation du temps. | Un temps correct est nécessaire pour TLS, journaux, audit, Kerberos/LDAP futur, monitoring et corrélation d'incidents. | La source NTP définitive peut être ajustée plus tard par inventaire. |
|
|
| `ssh_baseline` | Pose la base SSH : root interdit, clé publique obligatoire, mot de passe désactivé. | Force un accès administrateur par clé dès la construction du template. | Cloud-init doit avoir injecté le `ciuser` et sa clé avant Ansible. |
|
|
| `systemd_ssh_auto` | Désactive le comportement `systemd.ssh_auto` si demandé. | Évite une exposition SSH automatique via mécanismes transitoires non désirés dans un template serveur. | Ne remplace pas la politique SSH principale. |
|
|
| `motd` | Déploie un message d'accueil sobre. | Identifie le contexte de l_instance et rappelle que la machine est gérée par Set-OPS. | Ne doit pas contenir d'information sensible. |
|
|
| `hardening_packages` | Installe les paquets de sécurité communs. | Fournit les briques nécessaires au durcissement sans configurer de service applicatif. | Les politiques strictes par rôle restent appliquées sur les clones. |
|
|
| `sysctl_durcissement` | Applique des paramètres noyau de sécurité. | Réduit des comportements réseau et noyau risqués avec des réglages standards pour serveur Linux. | Les réglages spécifiques à une charge de travail peuvent être ajustés par rôle. |
|
|
| `core_dumps` | Désactive les core dumps. | Limite le risque de fuite de secrets ou données sensibles dans des dumps mémoire. | Un serveur de debug peut réactiver un comportement adapté hors template. |
|
|
| `unattended_upgrades` | Configure les mises à jour automatiques de sécurité. | Réduit l'exposition aux vulnérabilités connues sur les clones qui restent proches du socle. | Les redémarrages automatiques restent désactivés par défaut. |
|
|
| `apparmor` | Installe et active AppArmor. | Ajoute une couche de confinement standard Debian avec faible coût opérationnel. | Les profils applicatifs spécifiques seront gérés par les rôles applicatifs. |
|
|
| `auditd` | Installe auditd et des règles de base. | Fournit une trace système utile pour exploitation, investigation et conformité minimale. | Les règles lourdes ou propres à une application ne vont pas dans le template. |
|
|
| `fail2ban_ssh` | Active une protection SSH simple contre les essais répétés. | Réduit le bruit et les attaques opportunistes sur SSH sans dépendre d'une plateforme centrale. | Ne remplace pas un pare-feu ni une politique d'accès réseau. |
|
|
| `journald` | Limite l'usage disque et la rétention des journaux. | Évite qu'une VM issue du template remplisse son disque à cause des logs système. | La centralisation des logs viendra plus tard si nécessaire. |
|
|
| `ssh_durcissement` | Ajoute les paramètres SSH plus stricts : port, délais, tentatives, keepalive, forwarding et tunnels désactivés. | Réduit la surface d'exposition SSH sans dépendre d'un rôle applicatif. | Les exceptions, comme un bastion ou du forwarding contrôlé, doivent être portées par un rôle dédié. |
|
|
| `nftables_socle` | Installe nftables et prépare une configuration, mais garde le service désactivé par défaut. | Prépare le standard pare-feu sans risquer de couper l'accès au template ou aux clones. | L'activation se fait par rôle serveur avec règles adaptées. |
|
|
|
|
## Paquets communs
|
|
|
|
Les paquets communs sont choisis pour l'exploitation réelle :
|
|
|
|
```text
|
|
administration : sudo, acl, bash-completion, tmux, vim, nano
|
|
transport : curl, wget, ca-certificates, gnupg
|
|
ansible : python3, python3-apt, python3-pip
|
|
diagnostic : htop, iotop, iftop, sysstat, lsof, ncdu, tree, file, less
|
|
réseau : dnsutils, iproute2, iputils-ping, net-tools, traceroute, mtr-tiny, tcpdump, netcat-openbsd, socat
|
|
maintenance : rsync, unzip, zip, tar, jq, logrotate, unattended-upgrades, apt-listchanges, needrestart
|
|
virtualisation : qemu-guest-agent, cloud-init, cloud-guest-utils
|
|
temps : chrony
|
|
```
|
|
|
|
Ces paquets sont acceptés dans le template parce qu'ils sont utiles sur presque tous les serveurs et ne transforment pas la VM en serveur applicatif.
|
|
|
|
## Choix de sécurité importants
|
|
|
|
### SSH
|
|
|
|
État attendu dès la construction :
|
|
|
|
```text
|
|
PasswordAuthentication no
|
|
PermitRootLogin no
|
|
PubkeyAuthentication yes
|
|
AuthenticationMethods publickey
|
|
```
|
|
|
|
Le playbook `prepare` ne doit être lancé qu'après validation de l'accès SSH par clé au compte technique.
|
|
|
|
### Pare-feu
|
|
|
|
`nftables` est installé et préparé, mais désactivé par défaut.
|
|
|
|
Ce choix est volontaire : un pare-feu générique dans un template peut couper l'accès SSH ou bloquer un futur rôle serveur. L'activation doit être faite sur un clone avec des règles correspondant à son usage.
|
|
|
|
### Nettoyage final
|
|
|
|
Le nettoyage final est séparé et protégé par confirmation explicite. Il ne doit être lancé qu'au moment où la VM est validée et prête à être convertie en template.
|
|
|
|
## Vérification
|
|
|
|
```bash
|
|
make verifier-modele
|
|
```
|
|
|
|
## Validation minimale
|
|
|
|
Avant de déclarer le template prêt :
|
|
|
|
```bash
|
|
make verifier
|
|
make preparer-modele
|
|
make verifier-modele
|
|
```
|
|
|
|
La relance du playbook de préparation doit idéalement finir avec :
|
|
|
|
```text
|
|
failed=0
|
|
changed=0
|
|
```
|
|
|
|
## Nettoyage
|
|
|
|
```bash
|
|
make nettoyer-modele CONFIRMER=true
|
|
```
|
|
|
|
Ne pas lancer le nettoyage final sur un serveur de production ou sur une VM qui n'est pas destinée à devenir un template.
|
|
|
|
## Hors périmètre du template
|
|
|
|
Les éléments suivants ne doivent pas être installés dans le golden template :
|
|
|
|
```text
|
|
NGINX
|
|
PostgreSQL
|
|
MariaDB
|
|
Docker
|
|
Podman
|
|
Redis
|
|
GitLab
|
|
Nextcloud
|
|
monitoring complet
|
|
agents applicatifs spécialisés
|
|
données propres à un clone
|
|
secrets
|
|
clés privées
|
|
```
|
|
|
|
Les intégrations futures sont documentées dans :
|
|
|
|
```text
|
|
docs/integrations-vm.md
|
|
```
|
|
|
|
Le cycle complet VM vanille, golden template, clone et conformité continue est documenté dans :
|
|
|
|
```text
|
|
docs/vm-lifecycle.md
|
|
```
|