Skip to main content

Secret providers

Stocker les credentials DB dans un secret manager externe au lieu de la base Auralith. Supporte HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager.

Quand l'utiliser​

  • Politique securite interdit le stockage de secrets app-level.
  • Audit / certification (ISO 27001, SOC 2) qui demande un central secret store.
  • Rotation automatique des credentials DB sans toucher Auralith.

Workflow rapide​

  1. Admin -> Secret providers -> Ajouter.
  2. Choisir le type : vault, aws_secrets, gcp_secret_manager.
  3. Configurer les credentials d'acces au secret manager (token Vault, IAM role / access key AWS, service account JSON GCP).
  4. Tester la connexion au secret manager.
  5. A la creation d'une connexion DB, choisir "Stocker dans <provider>" au lieu de "Stocker localement". Auralith stocke uniquement la secret_path, resout la valeur a chaque connexion.

Concepts cles​

  • SecretProvider : config du backend de secrets. Plusieurs providers possibles par instance.
  • secret_path : chemin opaque dans le provider (ex: secret/data/auralith/prod-db pour Vault, ARN pour AWS).
  • Resolution lazy : le secret est resolu juste avant la connexion DB. Si le secret manager est down, la connexion echoue mais Auralith continue de tourner.

Pieges courants​

  • Auralith doit avoir acces reseau au secret manager. Ouvrez le firewall cote Vault / NACL AWS / firewall GCP.
  • Latence ajoutee : chaque connexion = un round-trip vers le secret manager. Negligeable si meme region, ressentie si cross-region.
  • Rotation Vault dynamic secrets : Auralith ne renew pas le lease. Pour des leases courts (moins d'1h), prevoir un proxy ou utiliser des static creds.
  • Plan Enterprise uniquement. Sur Starter / Pro, les secrets restent chiffres avec la SECRET_KEY locale.

Voir aussi​