Was Sie bekommen
${vault:keyName}-Referenzen in der Konfiguration für LLM, HTTP-Aufrufe, MCP und RAG- AES-256-GCM-Envelope-Verschlüsselung mit einem Datenschlüssel pro Tenant
- Grants pro Agent: welche Agenten welches Secret verwenden dürfen
- Secrets werden aus Konfigurationsexporten entfernt und in Logs geschwärzt
So funktioniert es in EDDI
- Den Master-Key des Vaults setzen (
EDDI_VAULT_MASTER_KEY). Der Installer erzeugt einen für Sie. Ohne Schlüssel ist der Vault deaktiviert. - Ein Secret mit
PUT /secretstore/secrets/{tenantId}/{keyName}oder über den Manager speichern. - In der Konfiguration als
${vault:keyName}referenzieren. - EDDI löst die Referenz zur Laufzeit auf. Der Klartext wird nicht im Konversationsgedächtnis gespeichert.
allowedAgentsauf die Agenten eingrenzen, die das Secret brauchen. Die Prüfung läuft beim Deployment eines Agenten.
Konfiguration
Aus der EDDI-Dokumentation übernommen. Platzhalter wie your-agent-id ersetzen Sie durch Ihre eigenen Werte.
curl -X PUT http://localhost:7070/secretstore/secrets/default/openai-key \
-H "Content-Type: application/json" \
-d '{"value":"sk-your-key","description":"OpenAI key"}'{
"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"
}
}]
}curl -X PUT "$EDDI/secretstore/secrets/default/openai-key/grant" \
-H 'Content-Type: application/json' \
-d '{"allowedAgents": ["0123456789abcdef01234567", "89abcdef0123456789abcdef"]}'Governance
- Grants werden standardmäßig beim Deployment durchgesetzt: Ein Agent, der ein Secret referenziert, für das er keinen Grant hat, wird nicht deployt.
- Eine Vault-Referenz, die über Konversationsdaten eintrifft, etwa als Nutzereingabe oder Modellantwort, wird abgelehnt statt aufgelöst.
- Klartext wird im Anfragedatensatz, in der Freigabe-Vorschau und in der Request-Logzeile geschwärzt.
- Bei aktiver Authentifizierung liegen die Vault-Endpunkte hinter der Rolle
eddi-admin.
Gut zu wissen
- EDDI hat keinen nativen Client für HashiCorp Vault, AWS oder Azure. Unter Kubernetes kann der External Secrets Operator das Kubernetes-Secret
eddi-secrets(das den Vault-Master-Key enthält) aus HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault synchronisieren. Die einzelnen Secrets liegen weiterhin im EDDI-Vault. - Geht der Master-Key verloren, sind die verschlüsselten Secrets nicht wiederherstellbar. Sichern Sie ihn.
Verwandte Integrationen
Konfiguration und Verhalten auf dieser Seite folgen der EDDI-Dokumentation, geprüft am 2026-10-14. Feldnamen und Standardwerte können sich zwischen Releases ändern. Bestätigen Sie sie daher in der Dokumentation Ihrer Version.