Daniel Allaire
8f6de3ebe2
Registres (source unique): - docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente. - docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN). Roles de service: - Reseau/edge/PKI/mail: nginx, step_ca, sendmail. - Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak. - Observabilite: prometheus, loki, grafana. - Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo. Integrations clientes: - clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp. Inventaire et outillage: - make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes-> playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature, deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault), robustesse reseau (connexions fermees, favicon). - Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre. - Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers 10.1.x; retrait des hotes de test; planification des hotes; requirements.yml. Chaque role valide en --syntax-check et ansible-lint (profil production). Secrets references depuis Ansible Vault (jamais en clair); roles non testes live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# clients_pki
|
|
|
|
Intégration cliente **PKI / identité machine** : chaque hôte fait confiance à l'AC
|
|
interne (`serveurs_step_ca`), obtient **son propre certificat** et le renouvelle
|
|
automatiquement.
|
|
|
|
## Rôle
|
|
- Installe `step-cli` (dépôt apt Smallstep).
|
|
- **Confiance** : `step ca bootstrap --install` → installe la racine de l'AC dans le
|
|
magasin de confiance système (l'hôte fait confiance au TLS interne réel).
|
|
- **Certificat d'hôte** : `step ca certificate <fqdn>` via le provisioner.
|
|
- **Renouvellement automatique** : unités systemd officielles `cert-renewer@.{service,timer}`
|
|
(vérifie/renouvelle toutes les 15 min, recharge le service consommateur s'il existe).
|
|
|
|
## « Chaque hôte authentifiable »
|
|
Après ce rôle, l'hôte possède une **identité machine** vérifiable : un certificat émis
|
|
par l'AC Chezlepro, renouvelé sans intervention. Les services peuvent l'utiliser pour
|
|
du TLS / mTLS interne.
|
|
|
|
## Secrets requis (Vault)
|
|
```yaml
|
|
clients_pki_ca_fingerprint: "{{ vault_step_ca_fingerprint }}" # empreinte racine de l'AC
|
|
clients_pki_provisioner_password: "{{ vault_step_ca_provisioner_password }}" # partage avec serveurs_step_ca
|
|
```
|
|
L'empreinte racine s'obtient sur l'AC (`step certificate fingerprint <root_ca.crt>`).
|
|
|
|
## Variables principales
|
|
| Variable | Défaut | Rôle |
|
|
| --- | --- | --- |
|
|
| `clients_pki_ca_url` | `https://infra-pki-01.chezlepro.internal:8443` | URL de l'AC |
|
|
| `clients_pki_provisioner` | `admin@chezlepro.internal` | Provisioner émetteur |
|
|
| `clients_pki_nom_cert` | FQDN de l'hôte | Nom du certificat |
|
|
|
|
## Notes / sécurité
|
|
- Émission via le provisioner **JWK** (mot de passe partagé) : tout hôte avec ce secret
|
|
peut émettre des certificats. Acceptable en interne ; pour durcir, basculer vers ACME
|
|
ou des jetons à usage unique par hôte (phase ultérieure).
|
|
- Pour qu'un service (nginx, keycloak…) recharge automatiquement après renouvellement,
|
|
nommer son certificat d'après le service (instance `cert-renewer@<service>`).
|
|
|
|
## Prérequis
|
|
- Dépendance `clients_pki requiert serveurs_step_ca actif` (déjà dans `docs/dependances-groupes.yml`).
|
|
- Réseau vers l'AC (`:8443`).
|