Aller au contenu

Rechercher dans la documentation

Saisissez votre recherche pour parcourir toutes les pages de la documentation.

Menu de la documentation
Guide pratiquePublic · Opérateurs et développeurs

Secrets avec Vault

Où Agent-Lab conserve ses secrets — et comment il les récupère

Cette page a été traduite automatiquement depuis l'anglais. En cas de divergence, la version originale fait foi.Lire l'original en anglais

Comment Agent-Lab utilise Vault

Agent-Lab utilise HashiCorp Vault pour une gestion sécurisée des secrets : les clés d'API, les identifiants de base de données et les autres valeurs sensibles résident dans Vault, et non dans la base de données ou dans des fichiers d'environnement. Au démarrage de l'application, la ConfigSource active se connecte à Vault et charge la charge utile de configuration ; les intégrations stockent des références dans la base de données, tandis que les valeurs sensibles sont récupérées depuis Vault à la demande.

Mettre en place Vault

Pour le développement local, les stacks Compose fournissent un serveur Vault avec une configuration de développement (interface à l'adresse http://localhost:8200, jeton de connexion dev-only-token). Voir Exécuter l'application.

Pour la production, provisionnez l'instance avec le module Terraform terraform/08_vault-instance/ décrit dans le guide de déploiement, y compris la séquence init + unseal :

kubectl --namespace vault exec vault-0 -- vault operator init \
    -key-shares=1 \
    -key-threshold=1 \
    -format=json > cluster-keys.json

export VAULT_UNSEAL_KEY=$(jq -r ".unseal_keys_b64[]" cluster-keys.json)
kubectl --namespace vault exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY

Provisionner la charge utile des secrets

VaultConfigSource lit un unique secret KV-v2 — point de montage secret, chemin app_secrets — et le fait correspondre aux clés de configuration de l'application. Les clés de la charge utile sont répertoriées dans la Référence de configuration ; écrivez-la une seule fois avec la CLI Vault :

vault kv put secret/app_secrets \
  api_base_url="https://<agent_lab_fqdn>" \
  cdp_url="http://<cdp_host>:9222" \
  auth_enabled="true" \
  auth_url="https://<auth_fqdn>" \
  auth_realm="<realm_name>" \
  auth_client_id="<client_name>" \
  auth_client_secret="<client_secret>" \
  broker_url="redis://:<password>@<redis_host>:6379/0" \
  db_url="postgresql://<user>:<pass>@<db_host>:5432/agent_lab" \
  db_vectors="postgresql://<user>:<pass>@<db_host>:5432/agent_lab_vectors" \
  db_checkpoints="postgresql://<user>:<pass>@<db_host>:5432/agent_lab_checkpoints"

Lorsque l'application ne peut pas (ou ne doit pas) utiliser un VAULT_TOKEN statique, la source par défaut bascule automatiquement sur KubernetesVaultConfigSource dès que VAULT_K8S_ROLE est défini — elle s'authentifie avec le jeton ServiceAccount projeté du pod, de sorte qu'aucun jeton statique n'a besoin d'être provisionné ni renouvelé.

Production

Conformément à nos principes cloud-native, nous recommandons la configuration Vault Kubernetes HA. Le module Terraform 15_agent-lab-dependencies/ configure les identifiants d'exécution ; l'application récupère l'ensemble au démarrage via le contrat de configuration.