195 lines
4.3 KiB
Markdown
195 lines
4.3 KiB
Markdown
|
|
# Cycle de vie des VM Chezlepro
|
||
|
|
|
||
|
|
Ce document décrit le cycle normal d'une VM Debian Chezlepro, depuis l'installation minimale jusqu'à la conformité continue par Ansible.
|
||
|
|
|
||
|
|
## Vue d'ensemble
|
||
|
|
|
||
|
|
```text
|
||
|
|
Debian 13 minimale
|
||
|
|
→ goldenisation du template
|
||
|
|
→ cleanup final
|
||
|
|
→ conversion Proxmox en template
|
||
|
|
→ clonage
|
||
|
|
→ identité initiale par cloud-init
|
||
|
|
→ conformité par groupes Ansible
|
||
|
|
→ intégrations par rôle
|
||
|
|
→ conformité continue
|
||
|
|
```
|
||
|
|
|
||
|
|
## 1. VM vanille
|
||
|
|
|
||
|
|
La VM vanille est une Debian 13 minimale installée manuellement ou par procédure Proxmox.
|
||
|
|
|
||
|
|
Elle contient seulement le nécessaire pour être joignable et prise en charge :
|
||
|
|
|
||
|
|
```text
|
||
|
|
Debian 13
|
||
|
|
SSH
|
||
|
|
réseau fonctionnel
|
||
|
|
cloud-init installé
|
||
|
|
CloudInit Drive Proxmox présent
|
||
|
|
utilisateur initial injecté par Cloud-Init
|
||
|
|
clé publique SSH injectée par Cloud-Init
|
||
|
|
sudo ou accès root possible
|
||
|
|
aucun rôle applicatif
|
||
|
|
aucun secret
|
||
|
|
```
|
||
|
|
|
||
|
|
Cette VM n'est pas encore un golden template Chezlepro.
|
||
|
|
|
||
|
|
## 2. Goldenisation
|
||
|
|
|
||
|
|
La goldenisation est faite par :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make preparer-modele
|
||
|
|
```
|
||
|
|
|
||
|
|
Ce playbook ajoute le socle Chezlepro commun au template :
|
||
|
|
|
||
|
|
```text
|
||
|
|
paquets communs
|
||
|
|
qemu-guest-agent
|
||
|
|
cloud-init
|
||
|
|
compte technique Ansible
|
||
|
|
chrony
|
||
|
|
SSH socle
|
||
|
|
durcissement template-safe
|
||
|
|
nftables préparé mais désactivé
|
||
|
|
```
|
||
|
|
|
||
|
|
Les détails et justifications sont dans :
|
||
|
|
|
||
|
|
```text
|
||
|
|
docs/modeles_vm/debian13-proxmox.md
|
||
|
|
```
|
||
|
|
|
||
|
|
## 3. Validation et cleanup
|
||
|
|
|
||
|
|
Après la préparation :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make verifier-modele
|
||
|
|
```
|
||
|
|
|
||
|
|
Le cleanup final est séparé et protégé :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make nettoyer-modele CONFIRMER=true
|
||
|
|
```
|
||
|
|
|
||
|
|
Le cleanup ne doit jamais être lancé sur une VM de production.
|
||
|
|
|
||
|
|
## 4. Clonage
|
||
|
|
|
||
|
|
Le clone reçoit son identité initiale par Proxmox et cloud-init :
|
||
|
|
|
||
|
|
```text
|
||
|
|
hostname
|
||
|
|
utilisateur initial
|
||
|
|
clé SSH
|
||
|
|
IP ou DHCP
|
||
|
|
passerelle
|
||
|
|
DNS
|
||
|
|
agrandissement disque
|
||
|
|
```
|
||
|
|
|
||
|
|
Cloud-init ne remplace pas Ansible pour la configuration réelle du serveur.
|
||
|
|
|
||
|
|
## 5. Groupes opérationnels
|
||
|
|
|
||
|
|
Une VM déployée doit être placée dans les groupes d'inventaire qui décrivent l'état voulu.
|
||
|
|
|
||
|
|
Chaque groupe opérationnel doit avoir un playbook homonyme :
|
||
|
|
|
||
|
|
```text
|
||
|
|
serveurs_debian -> playbooks/groupes/serveurs_debian.yml
|
||
|
|
serveurs_durcis -> playbooks/groupes/serveurs_durcis.yml
|
||
|
|
```
|
||
|
|
|
||
|
|
L'appartenance aux groupes devient la déclaration d'intention :
|
||
|
|
|
||
|
|
```text
|
||
|
|
web-01 dans serveurs_debian -> applique le socle Debian
|
||
|
|
web-01 dans serveurs_durcis -> applique le durcissement commun
|
||
|
|
```
|
||
|
|
|
||
|
|
Un groupe sans playbook ne doit pas être assigné à une VM de production tant que son rôle n'est pas implémenté.
|
||
|
|
|
||
|
|
## 6. Socle Debian
|
||
|
|
|
||
|
|
Le groupe `serveurs_debian` maintient les composants de base :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make appliquer GROUPE=serveurs_debian
|
||
|
|
```
|
||
|
|
|
||
|
|
## 7. Hardening commun
|
||
|
|
|
||
|
|
Le groupe `serveurs_durcis` maintient les couches de sécurité communes :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make appliquer GROUPE=serveurs_durcis
|
||
|
|
```
|
||
|
|
|
||
|
|
L'accès SSH par mot de passe est désactivé dès le socle. L'activation de nftables doit rester dépendante des règles réseau propres au rôle du serveur.
|
||
|
|
|
||
|
|
## 8. Déploiement par Makefile
|
||
|
|
|
||
|
|
Pour une VM déjà clonée et démarrée :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make hote-ajouter HOTE=web-01 ADRESSE_IP=192.168.12.101 GROUPES="serveurs_debian serveurs_durcis"
|
||
|
|
make deployer HOTE=web-01
|
||
|
|
```
|
||
|
|
|
||
|
|
La cible `deployer` lit les groupes de l'hôte, cherche les playbooks correspondants dans `playbooks/groupes/`, puis les applique dans l'ordre de l'inventaire.
|
||
|
|
|
||
|
|
Ensuite, elle lance la vérification post-déploiement :
|
||
|
|
|
||
|
|
```text
|
||
|
|
playbooks/groupes/serveurs_debian.yml
|
||
|
|
playbooks/groupes/serveurs_durcis.yml
|
||
|
|
verifier-hote
|
||
|
|
```
|
||
|
|
|
||
|
|
Pour converger un groupe complet :
|
||
|
|
|
||
|
|
```bash
|
||
|
|
make deployer-groupe GROUPE=serveurs_debian
|
||
|
|
```
|
||
|
|
|
||
|
|
## 9. Variables template et conformité
|
||
|
|
|
||
|
|
Les variables du template servent à construire le golden template dans `inventories/lab/group_vars/modeles_vm.yml`.
|
||
|
|
|
||
|
|
Les variables de conformité servent aux VM déployées dans `inventories/production/group_vars/serveurs_debian.yml`.
|
||
|
|
|
||
|
|
Différence attendue :
|
||
|
|
|
||
|
|
```text
|
||
|
|
template : SSH par clé seulement, pare-feu non activé
|
||
|
|
conformité VM : même base SSH, règles réseau adaptées aux serveurs finaux
|
||
|
|
```
|
||
|
|
|
||
|
|
Ne pas durcir une variable de conformité si son application peut couper l'accès sans validation préalable.
|
||
|
|
|
||
|
|
## 10. Intégrations futures
|
||
|
|
|
||
|
|
Les intégrations transversales sont ajoutées après socle et durcissement :
|
||
|
|
|
||
|
|
```text
|
||
|
|
DNS interne
|
||
|
|
PKI interne
|
||
|
|
identité
|
||
|
|
supervision
|
||
|
|
métriques
|
||
|
|
visualisation
|
||
|
|
```
|
||
|
|
|
||
|
|
Elles sont documentées dans :
|
||
|
|
|
||
|
|
```text
|
||
|
|
docs/integrations-vm.md
|
||
|
|
```
|