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> |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| tasks | ||
| templates | ||
| README.md | ||
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)
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à dansdocs/dependances-groupes.yml). - Réseau vers l'AC (
:8443).