Gestion des secrets

Aucune valeur de secret dans cette documentation

Cette page décrit uniquement le mécanisme de gestion des secrets du projet. Aucun mot de passe, clé privée, token ou identifiant réel n'est reproduit ici, y compris à titre d'exemple. Un incident antérieur de clés privées TLS committées par erreur a confirmé la nécessité de cette règle stricte pour tout ce qui touche à ce dépôt de documentation.

Principes

  • Aucun terraform.tfvars réel n'est versionné : seul le .tfvars.example (variables nommées, valeurs bidons) est commité. Le fichier réel est gitignoré dans chaque projet.
  • Les mots de passe Ansible (SSH/sudo) sont fournis en extra-vars au moment de l'exécution, jamais stockés en clair dans un rôle ou un playbook.
  • Les valeurs sensibles utilisées par Ansible sont chiffrées avec ansible-vault, un fichier de mot de passe dédié par projet (hors de tout dépôt git, permissions 0600) référencé via vault_password_file dans ansible.cfg.
  • Les secrets applicatifs partagés (credentials de service, clés API, secrets AWS utilisés pour l'auto-unseal) sont centralisés dans HashiCorp Vault (KV-v2) — voir Vault & PKI.
  • Les hachages de mots de passe système (rotation de comptes) sont générés à la volée et passés en extra-var, jamais committés.
  • Le token API utilisé par les data sources Terraform NetBox (lookup d'IP) est un token en lecture seule (write_enabled=false) : il ne peut pas altérer l'IPAM, même s'il apparaît dans un terraform.tfvars local.

Rotation

Toute rotation de secret partagé par plusieurs projets (ex. mot de passe des comptes système de la flotte) doit être répercutée dans l'ensemble des fichiers de secrets Ansible qui en dépendent avant de rejouer un playbook — un défaut de synchronisation casse silencieusement la connexion des playbooks suivants.

Comptes de service dédiés

Les intégrations automatisées (Terraform, Packer, et plus généralement tout accès programmatique à vCenter) utilisent des comptes de service SSO dédiés, distincts des comptes humains, avec un rôle vCenter restreint aux seuls privilèges nécessaires (VM/datastore/réseau/pool de ressources — pas d'administration hôte/cluster/permissions). Voir vCenter & hôtes ESXi.

Comptes cloud AWS

Le compte AWS utilisé pour l'auto-unseal Vault (KMS) et le stockage S3 (tfstate, archivage) est un compte réel, distinct de tout compte de lab. Les utilisateurs IAM dédiés sont scopés au strict nécessaire (KMS seul pour l'un, ARN S3 explicites pour l'autre — jamais de Resource: "*" pour l'accès S3). Les clés d'accès correspondantes ne sont conservées que hors dépôt (fichier de credentials local et Vault), jamais en clair dans un fichier suivi par git.