Skip to content
🚀 EDDI 6.5.0

19 fournisseurs LLM, des bases de connaissances qui explorent votre site et lisent vos fichiers, et des conversations qui suivent les versions compatibles des agentsNouveautés

Cloud Géré Démarrer
Toutes les intégrations
Identité et sécurité${vault:}

Secrets Vault

Un coffre de secrets intégré, à chiffrement par enveloppe. La configuration référence les secrets sous la forme ${vault:keyName}, et la valeur n'atterrit jamais dans les configurations d'agents, les exports ou les journaux.

Ce que vous obtenez

  • Des références ${vault:keyName} dans la configuration des LLM, des appels HTTP, de MCP et du RAG
  • Un chiffrement par enveloppe AES-256-GCM avec une clé de données par tenant
  • Des autorisations par agent : quels agents peuvent utiliser quel secret
  • Des secrets retirés des exports de configuration et masqués dans les journaux

Fonctionnement dans EDDI

  1. Définir la clé maître du coffre (EDDI_VAULT_MASTER_KEY). L'installateur en génère une pour vous. Sans clé, le coffre est désactivé.
  2. Stocker un secret avec PUT /secretstore/secrets/{tenantId}/{keyName} ou via le Manager.
  3. Le référencer dans la configuration avec ${vault:keyName}.
  4. EDDI résout la référence à l'exécution. Le texte en clair n'est pas stocké dans la mémoire de conversation.
  5. Restreindre allowedAgents aux agents qui ont besoin du secret. La vérification s'exécute au déploiement d'un agent.

Configuration

Tirée de la documentation d'EDDI. Les espaces réservés comme your-agent-id sont à remplacer par vos propres valeurs.

Store a secretStocker un secret. La réponse ne renvoie jamais la valeur.
curl -X PUT http://localhost:7070/secretstore/secrets/default/openai-key \
  -H "Content-Type: application/json" \
  -d '{"value":"sk-your-key","description":"OpenAI key"}'
langchain.json (reference it, never paste it)Référencer le secret par son nom depuis une tâche LLM.
{
  "tasks": [{
    "actions": ["send_message"],
    "id": "simpleChat",
    "type": "openai",
    "description": "Simple chat",
    "parameters": {
      "apiKey": "${vault:openai-key}",
      "modelName": "your-model-id",
      "systemMessage": "You are a helpful assistant",
      "addToOutput": "true"
    }
  }]
}
Grant one secret to specific agentsModifier qui peut utiliser un secret sans toucher à sa valeur.
curl -X PUT "$EDDI/secretstore/secrets/default/openai-key/grant" \
  -H 'Content-Type: application/json' \
  -d '{"allowedAgents": ["0123456789abcdef01234567", "89abcdef0123456789abcdef"]}'

Gouvernance

  • Les autorisations sont appliquées au déploiement par défaut : un agent qui référence un secret qu'il n'a pas le droit d'utiliser n'est pas déployé.
  • Une référence au coffre qui arrive par les données de conversation, comme une saisie utilisateur ou une réponse du modèle, est refusée au lieu d'être résolue.
  • Le texte en clair est masqué dans l'enregistrement de la requête, dans l'aperçu de validation et dans la ligne de journal de la requête.
  • Lorsque l'authentification est activée, les points d'accès du coffre sont protégés par le rôle eddi-admin.

Bon à savoir

  • EDDI n'a pas de client natif pour HashiCorp Vault, AWS ou Azure. Sous Kubernetes, l'External Secrets Operator peut synchroniser le Secret Kubernetes eddi-secrets (qui contient la clé maître du coffre) depuis HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault. Les secrets individuels restent dans le coffre d'EDDI.
  • Si la clé maître est perdue, les secrets chiffrés sont irrécupérables. Sauvegardez-la.

Intégrations associées

La configuration et le comportement décrits sur cette page suivent la documentation d'EDDI, vérifiée le 2026-10-14. Les noms de champs et les valeurs par défaut peuvent changer d'une version à l'autre : confirmez-les dans la documentation de votre version.