Secrets mit Vault · Agent-Lab

Wie Agent-Lab Vault verwendet

Agent-Lab verwendet HashiCorp Vault für die sichere Verwaltung von Secrets: API-Schlüssel, Datenbank-Zugangsdaten und andere sensible Werte liegen in Vault, nicht in der Datenbank oder in Umgebungsdateien. Beim Start der Anwendung verbindet sich die aktive ConfigSource mit Vault und lädt die Konfigurations-Payload; Integrationen speichern Referenzen in der Datenbank, während die sensiblen Werte bei Bedarf aus Vault abgerufen werden.

Vault einrichten

Für die lokale Entwicklung enthalten die Compose-Stacks einen Vault-Server mit einer Entwicklungskonfiguration (UI unter http://localhost:8200, Login-Token dev-only-token). Siehe Die Anwendung ausführen.

Für die Produktion stellen Sie die Instanz mit dem Terraform-Modul terraform/08_vault-instance/ aus dem Deployment-Guide bereit – einschließlich der Sequenz aus 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

Die Secret-Payload bereitstellen

VaultConfigSource liest ein einzelnes KV-v2-Secret – Mount secret, Pfad app_secrets – und bildet es auf die Konfigurationsschlüssel der Anwendung ab. Die Payload-Schlüssel sind in der Konfigurationsreferenz aufgeführt; schreiben Sie sie einmalig mit der Vault-CLI:

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"

Wenn die Anwendung kein statisches VAULT_TOKEN verwenden kann (oder soll), wechselt die Standardquelle automatisch zu KubernetesVaultConfigSource, sobald VAULT_K8S_ROLE gesetzt ist – sie authentifiziert sich mit dem projizierten ServiceAccount-Token des Pods, sodass kein statisches Token bereitgestellt oder rotiert werden muss.

Produktion

Gemäß unseren Cloud-nativen Prinzipien empfehlen wir das Vault-Kubernetes-HA-Setup. Das Terraform-Modul 15_agent-lab-dependencies/ verdrahtet die Laufzeit-Zugangsdaten; die Anwendung übernimmt beim Start alles über den Konfigurationsvertrag.