wiki : unités PKI, DNS, Sauvegardes (Fondations complètes + Données)
3 unités au moule à 4 temps : PKI & confiance (step-ca, chaîne, ACME, mTLS), DNS & résolution (les 3 couches, le plancher), Sauvegardes (3-2-1, restaurer-pour-prouver). Fondations = Identité + PKI + DNS complètes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
3964a712b1
commit
b342e5796b
4 changed files with 253 additions and 3 deletions
78
wiki/DNS-et-résolution.md
Normal file
78
wiki/DNS-et-résolution.md
Normal file
|
|
@ -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*.
|
||||
84
wiki/PKI-et-confiance.md
Normal file
84
wiki/PKI-et-confiance.md
Normal file
|
|
@ -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 2>/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**.
|
||||
88
wiki/Sauvegardes.md
Normal file
88
wiki/Sauvegardes.md
Normal file
|
|
@ -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).
|
||||
|
|
@ -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)*
|
||||
|
|
|
|||
Loading…
Reference in a new issue