diff --git a/wiki/DNS-et-résolution.md b/wiki/DNS-et-résolution.md new file mode 100644 index 0000000..33f6577 --- /dev/null +++ b/wiki/DNS-et-résolution.md @@ -0,0 +1,78 @@ +# DNS & résolution de noms + +> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. + +--- + +## ① Le concept *(générique)* + +Les machines se parlent par **adresses IP** ; les humains (et les configs) utilisent des **noms**. +La **résolution de noms** fait le pont : `keycloak.lab…` → `192.168.15.21`. + +Plusieurs couches, de la plus locale à la plus globale : +- **Fichier hosts** (`/etc/hosts`) : une table statique, locale, **consultée en premier**, **sans + aucun réseau**. Increvable, mais manuelle. +- **DNS autoritatif** : le serveur qui **détient la vérité** d'une zone (ex. `lab.chezlepro.internal`) + et répond pour ses noms (enregistrements **A**, **SOA**…). +- **DNS récursif (résolveur)** : celui que tes machines interrogent ; il **cherche pour toi** + (cache local, puis interne, puis Internet). + +Distinction-clé souvent floue : **autoritatif** (« je *possède* ce nom ») ≠ **récursif** (« je *vais +chercher* la réponse pour toi »). + +--- + +## ② Comment Set-OPS le fait — **trois couches** + +| Couche | Pièce | Propriété | +|---|---|---| +| **1. Le plancher** | `hosts_statiques` (socle) → `/etc/hosts` sur **chaque** nœud | résout **même DNS éteint**, dès le bootstrap. Le filet en dessous de tout. | +| **2. Autoritatif** | `serveur_powerdns` (PowerDNS) | la zone interne, les enregistrements **A**. | +| **3. Récursif local** | `client_unbound` (**opt-in**) | résolveur local : stub-zone → PowerDNS pour l'interne, récursion pour le reste. | + +Le **plancher** est le cœur pédagogique : parce que chaque nœud connaît *tout l'écosystème* par +`/etc/hosts`, **rien ne dépend du DNS pour démarrer** — PowerDNS devient une *commodité*, pas un +point de défaillance unique. On construit la robustesse **de bas en haut**. + +C'est aussi ce que **tu** utilises depuis ta machine : mettre `192.168.15.21 keycloak.lab…` dans +ton `/etc/hosts`, c'est exactement le même « plancher ». + +--- + +## ③ Pourquoi c'est transférable + +| Set-OPS | Équivalents ailleurs | +|---|---| +| `/etc/hosts` | identique sur tout OS (Linux, macOS, Windows) | +| PowerDNS autoritatif | BIND · Knot · NSD · Route 53 / Cloud DNS (autoritatifs) | +| Unbound récursif | `systemd-resolved` · dnsmasq · le résolveur de ton FAI · 1.1.1.1 | + +Tu as appris **la hiérarchie de résolution** (hosts → récursif → autoritatif) et la distinction +**autoritatif/récursif** — pas « PowerDNS ». Ça vaut partout. + +--- + +## ④ À toi de jouer + +1. **Le plancher, sans DNS.** Sur un nœud : + ```bash + getent hosts keycloak.lab.chezlepro.internal # répond via /etc/hosts, zéro DNS + grep chezlepro /etc/hosts | head + ``` +2. **Interroge l'autoritatif.** Demande à PowerDNS directement : + ```bash + dig @infra-dns-01.lab.chezlepro.internal keycloak.lab.chezlepro.internal A +short + dig @infra-dns-01.lab.chezlepro.internal lab.chezlepro.internal SOA +short + ``` +3. **Vois les couches.** Compare `getent hosts` (plancher) et `dig` (DNS) : **deux chemins**, même IP. +4. **Casse & répare.** Sur un nœud **sans** `client_unbound`, vide `/etc/hosts` de ses entrées + `chezlepro` (garde une sauvegarde !) et coupe l'accès au DNS : la résolution interne **échoue**. + Restaure `/etc/hosts` : ça remarche **sans DNS**. Tu viens de *sentir* pourquoi le plancher est le + filet de sécurité. + +--- + +## Pour aller plus loin *(dépôt)* +- Rôles : `roles/hosts_statiques` (le plancher), `roles/serveur_powerdns`, `roles/client_unbound`. +- Conception des 3 couches + frontière publique : `docs/dns-interne.md`. +- Note : `client_unbound` est une **liaison optionnelle** (opt-in) — voir l'unité *Liaisons*. diff --git a/wiki/PKI-et-confiance.md b/wiki/PKI-et-confiance.md new file mode 100644 index 0000000..5a2a6e4 --- /dev/null +++ b/wiki/PKI-et-confiance.md @@ -0,0 +1,84 @@ +# PKI & confiance + +> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. + +--- + +## ① Le concept *(générique)* + +**Chiffrement asymétrique** : une **paire de clés** — une **privée** (secrète) et une **publique** +(partageable). Ce que l'une chiffre, l'autre le déchiffre. La privée **signe**, la publique **vérifie**. + +**Un certificat** = une clé publique + une identité (« ce serveur est `id-ldap-01` »), le tout +**signé** par une autorité. Il répond à : *« à qui est-ce que je parle, vraiment ? »* + +**L'autorité de certification (AC / CA)** signe les certificats. On lui fait confiance, donc on fait +confiance à ce qu'elle signe. **Chaîne de confiance** : une **racine** (hors-ligne, précieuse) signe +une **intermédiaire**, qui signe les certificats des serveurs. Faire confiance à la racine = faire +confiance à toute la chaîne. + +**mTLS** (TLS mutuel) : les **deux** parties présentent un certificat — chacune prouve son identité. + +**ACME** : le **protocole d'automatisation** de l'émission/renouvellement des certificats +(popularisé par Let's Encrypt). + +--- + +## ② Comment Set-OPS le fait + +| Pièce | Rôle | Concept incarné | +|---|---|---| +| **step-ca** (`serveur_step_ca`) | l'**autorité de certification** interne (racine + intermédiaire, base des émissions). | AC, chaîne de confiance | +| **client_pki** (`client_pki`) | intégration : un nœud **obtient un certificat** de l'AC (via ACME) et **fait confiance à la racine**. | émission ACME, magasin de confiance | + +Le motif : chaque service qui doit prouver son identité (LDAPS d'OpenLDAP, HTTPS de l'edge…) +reçoit un **certificat d'hôte** signé par step-ca ; la **racine** est déposée dans le **magasin de +confiance système** de chaque nœud. Résultat : les nœuds se parlent en **TLS vérifié**, sans +avertissement, **sans dépendre d'une AC publique**. La souveraineté commence par sa propre confiance. + +Le **Tier 0** des sauvegardes, c'est justement `/etc/step-ca` (les **clés** de l'AC) — perdre la +racine = tout re-émettre et re-truster. *(voir l'unité Sauvegardes.)* + +--- + +## ③ Pourquoi c'est transférable + +| Set-OPS | Équivalents ailleurs | +|---|---| +| step-ca (AC interne) | HashiCorp Vault PKI · AD Certificate Services · EJBCA · une AC OpenSSL maison | +| ACME interne | Let's Encrypt (public) · ZeroSSL · tout serveur ACME | +| racine dans le magasin système | exactement le même mécanisme que les AC publiques préchargées dans ton OS/navigateur | + +Tu as appris **la PKI, la chaîne de confiance, ACME, mTLS** — pas « step-ca ». Ça vaut pour Let's +Encrypt, Vault, une AC d'entreprise : le schéma est **identique**. + +--- + +## ④ À toi de jouer + +1. **Regarde un certificat.** Sur un nœud avec `client_pki` : + ```bash + openssl x509 -in /etc/step/certs/$(hostname -f).crt -noout -subject -issuer -dates + ``` + Repère le **sujet** (l'identité), l'**émetteur** (l'intermédiaire) et la **validité**. +2. **Suis la chaîne de confiance.** + ```bash + openssl verify -CAfile /etc/step/certs/root_ca.crt /etc/step/certs/$(hostname -f).crt + ``` + `OK` = la racine valide bien le certificat du serveur. C'est ① en action. +3. **Vois-le servir en vrai.** Le LDAPS d'OpenLDAP utilise ce certificat : + ```bash + openssl s_client -connect id-ldap-01.lab.chezlepro.internal:636 \ + -CAfile /etc/step/certs/root_ca.crt /dev/null | grep -E 'Verify return code' + ``` + `0 (ok)` = confiance vérifiée. +4. **Casse & répare.** Retire la racine du magasin système, refais un `curl` HTTPS interne : + **avertissement de certificat** (plus de confiance). Réinstalle la racine : ça remarche. Tu viens + de *sentir* pourquoi « faire confiance à la racine » est la clé de voûte. + +--- + +## Pour aller plus loin *(dépôt)* +- Rôles : `roles/serveur_step_ca`, `roles/client_pki`. +- Le motif « pont de certificat » (renouvellement automatique) : voir les tâches `*-cert-sync` des rôles (Dovecot, Postfix, nginx…). +- Tier 0 des sauvegardes (`/etc/step-ca`) : unité **Sauvegardes**. diff --git a/wiki/Sauvegardes.md b/wiki/Sauvegardes.md new file mode 100644 index 0000000..cd83d99 --- /dev/null +++ b/wiki/Sauvegardes.md @@ -0,0 +1,88 @@ +# Sauvegardes (3-2-1) + +> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. + +--- + +## ① Le concept *(générique)* + +**Sauvegarder quoi ?** Pas forcément « tout ». Si ton infra est **reconstructible** (par du code), +les machines ne sont pas précieuses — c'est la **donnée d'état** (non régénérable) qui l'est. + +**La règle 3-2-1** : **3** copies, sur **2** supports, dont **1** hors-site. Une seule copie n'est +pas une sauvegarde. + +**Logique vs image** : *logique* = un export applicatif cohérent (`pg_dump`, `slapcat`) ; *image* = +une copie brute du disque/VM. La logique est fine et portable ; l'image est grosse et rapide à +restaurer. + +**La vérité qui fait mal** : *une sauvegarde jamais restaurée n'existe pas.* La **restauration +testée** est le seul critère. « Ça a tourné » ≠ « ça restaure ». + +Trois propriétés d'une bonne sauvegarde : **chiffrée** (au repos), **dédupliquée** (économe), +**avec rétention** (garder N jours/semaines, purger le reste). + +--- + +## ② Comment Set-OPS le fait + +Choix fondateur : **sauvegarder la donnée** (l'infra est reconstructible par le code + le template), +**pas les VM**. + +| Pièce | Rôle | +|---|---| +| **restic** | l'outil : chiffrement côté client, déduplication, rétention. | +| **`serveur_backup`** | la **cible** hors-nœud (un dépôt restic par nœud). | +| **`client_backup`** | intégration par nœud : **jobs déclaratifs** (dump + chemins), timer quotidien, rétention. | + +Ce qu'on protège, par **tiers** : +- **Tier 0 (vital)** : les **clés de la CA** step-ca (`/etc/step-ca`) — l'ancre de confiance, irremplaçable. +- **Tier 1 (critique)** : bases PostgreSQL (`pg_dumpall`), annuaire LDAP (`slapcat`), boîtes + `/var/vmail`, dépôts Forgejo. + +**Prouvé, pas supposé** : chaque tier a été **restauré** et vérifié (clés CA byte-identiques, les 3 +bases PostgreSQL présentes, `testmail` retrouvé dans l'export LDAP). + +--- + +## ③ Pourquoi c'est transférable + +| Set-OPS | Équivalents ailleurs | +|---|---| +| restic | BorgBackup · Restic partout · Duplicity | +| dépôt hors-nœud | NFS · S3/MinIO · un NAS · un cloud souverain | +| 3-2-1, restauration testée | **principes universels** — vrais pour Veeam, tar+cron, ou un cloud | + +Tu as appris **quoi sauvegarder, la règle 3-2-1, logique vs image, et surtout restaurer-pour-prouver** +— pas « restic ». Ça vaut pour n'importe quel outil. + +--- + +## ④ À toi de jouer + +1. **Lance une sauvegarde.** Sur un nœud avec `client_backup` : + ```bash + /usr/local/sbin/setops-sauvegarder.sh + ``` +2. **Liste les instantanés** (le dépôt vit hors-nœud) : + ```bash + export RESTIC_REPOSITORY=sftp:restic@backup-01.lab.chezlepro.internal:$(hostname) + export RESTIC_PASSWORD_FILE=/etc/setops/restic.pass + restic snapshots + ``` +3. **Restaure — le vrai test.** Restaure dans un dossier temporaire et **compare** : + ```bash + restic restore latest --target /tmp/rst + diff -r /etc/step-ca /tmp/rst/etc/step-ca && echo "RESTAURATION FIDÈLE" + ``` + *(sur infra-pki-01 ; ailleurs, compare le dump correspondant.)* +4. **Casse & répare.** Supprime un fichier de donnée (une copie de test !), restaure-le depuis + l'instantané, vérifie qu'il est **identique**. Tu viens de *sentir* que la valeur d'une sauvegarde + est **la restauration**, pas la sauvegarde. + +--- + +## Pour aller plus loin *(dépôt)* +- Rôles : `roles/serveur_backup`, `roles/client_backup`. +- Philosophie « donnée, pas VM » + les tiers : voir le CHANGELOG (entrée sauvegardes) et les jobs en host_vars. +- Complément 3-2-1 (offsite) : reste à faire — c'est l'**Étape B** (frontière publique). diff --git a/wiki/_Sidebar.md b/wiki/_Sidebar.md index 6e81cba..ca1b399 100644 --- a/wiki/_Sidebar.md +++ b/wiki/_Sidebar.md @@ -5,8 +5,8 @@ *Fondations* - [Identité & SSO](Identité-et-SSO) ✅ -- PKI & confiance *(à venir)* -- DNS & résolution de noms *(à venir)* +- [PKI & confiance](PKI-et-confiance) ✅ +- [DNS & résolution de noms](DNS-et-résolution) ✅ *Communication* - Reverse-proxy & TLS *(à venir)* @@ -15,7 +15,7 @@ *Données* - Bases de données *(à venir)* - Cache *(à venir)* -- Sauvegardes (3-2-1) *(à venir)* +- [Sauvegardes (3-2-1)](Sauvegardes) ✅ *Observabilité* - Métriques & journaux *(à venir)*