Les deux depots prives sont miroites via un jeton de lecture seule (vault_miroir_amont). Ils restent lisibles sur la forge de patient 0 : c'est ainsi que son poste les clone, en anonyme, sans detenir de justificatif. Le gabarit de voute reclamait encore proxmox_api_token_id/secret d'un tenant qui ne doit pas les detenir : depuis la separation des voutes, le jeton du cluster appartient a l'hebergeur, et proxmox_api.voute() lui donne raison quand les deux portent la cle. Un jeton pose dans le tenant serait ignore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
3.7 KiB
Text
58 lines
3.7 KiB
Text
---
|
|
# GABARIT de voute de patient 0 — des NOMS, jamais de valeurs.
|
|
#
|
|
# La voute reelle (group_vars/all/vault.yml, chiffree) se cree a la main :
|
|
# ansible-vault create inventories/production/group_vars/all/vault.yml
|
|
# Son mot de passe ne vit NI ici, NI dans aucun depot : c'est le seul objet que la
|
|
# reproduction exige d'un humain. Le mettre dans la forge reviendrait a enfermer la
|
|
# cle dans le coffre.
|
|
#
|
|
# P18 confronte ce gabarit aux secrets que le plan exige, puis la voute reelle a ce
|
|
# gabarit. Une cle qui manque ici passe inapercue jusqu'au deploiement.
|
|
|
|
# --- Exiges par des roles que patient 0 DEPLOIE ---
|
|
vault_backup_ssh_privkey: "" # role client_backup
|
|
vault_bd_forgejo: "" # base 'forgejo'
|
|
vault_forgejo_admin: "" # role serveur_forgejo
|
|
vault_forgejo_internal_token: "" # role serveur_forgejo
|
|
vault_forgejo_oidc: "" # role serveur_forgejo
|
|
vault_forgejo_secret_key: "" # role serveur_forgejo
|
|
vault_openldap_admin: "" # role amorcage_acces (playbook serveur_openldap.yml)
|
|
vault_postgresql_keycloak: "" # role serveur_postgresql
|
|
vault_redis: "" # role serveur_redis
|
|
vault_restic_password: "" # role client_backup
|
|
vault_step_ca_password: "" # role serveur_step_ca
|
|
vault_step_ca_provisioner_password: "" # role client_pki
|
|
|
|
# --- Exiges par le harnais, pour des services que patient 0 NE DEPLOIE PAS ---
|
|
# Ces references vivent dans des roles que patient 0 installe (ex. serveur_backup
|
|
# pousse ses resultats vers Icinga, serveur_postgresql connait les bases des
|
|
# autres). Le perimetre est donc plus large que la flotte : meme question de
|
|
# cadrage que celle corrigee sur P32 le 2026-08-20. Les laisser vides tant que le
|
|
# service correspondant n'existe pas.
|
|
vault_grafana_admin: "" # role serveur_grafana (playbook serveur_grafana.yml)
|
|
vault_grafana_oidc: "" # role serveur_grafana (playbook serveur_grafana.yml)
|
|
vault_icinga_api_depot: "" # role serveur_backup (playbook serveur_backup.yml)
|
|
vault_keycloak_admin: "" # role serveur_keycloak (playbook serveur_keycloak.yml)
|
|
vault_nextcloud_admin: "" # role serveur_nextcloud (playbook serveur_nextcloud.yml)
|
|
vault_nextcloud_oidc: "" # role serveur_nextcloud (playbook serveur_nextcloud.yml)
|
|
vault_oauth2_cookie: "" # role serveur_oauth2_proxy (playbook serveur_oauth2_proxy.yml)
|
|
vault_sysadmin_amorcage: "" # role amorcage_acces (playbook serveur_openldap.yml)
|
|
|
|
# --- Acces au CLUSTER, exiges hors motif `vault_` ---
|
|
# Ces deux-la ne commencent pas par `vault_` et echappent donc au reperage automatique :
|
|
# c'est P18 qui les exige nommement. Ils ouvrent l'API Proxmox pour cloner les VM.
|
|
#
|
|
# LES JETONS PROXMOX NE SONT PLUS ICI (separation des voutes, 2026-08-22).
|
|
#
|
|
# Le jeton d'API du cluster appartient a l'HEBERGEUR, pas a l'organisation hebergee. Il
|
|
# vit desormais dans la voute du site — `SITE-Chezlepro/underlay.vault.yml` — avec la cle
|
|
# de la frontiere. Recopie dans la voute de chaque tenant, il ne pouvait plus etre revoque
|
|
# isolement : retirer l'acces d'un locataire revenait a le retirer a tous.
|
|
#
|
|
# `proxmox_api.voute()` lit la voute du tenant PUIS celle de l'underlay, et c'est celle de
|
|
# l'hebergeur qui fait foi quand les deux portent la cle. Un jeton pose ici serait donc
|
|
# ignore — mieux vaut ne pas le poser du tout que croire qu'il sert.
|
|
#
|
|
# Constate le 2026-08-23 : ce gabarit reclamait encore `proxmox_api_token_id` et
|
|
# `proxmox_api_token_secret` d'un tenant qui ne doit pas les detenir.
|