Credentials et secrets
Un credential Knot stocke un secret (clé API, mot de passe SMTP partenaire, secret webhook) chiffré. Le moteur déchiffre uniquement au moment d’un run, sans l’afficher dans les logs utilisateur.
🔐 Chiffrement
- Algorithme : AES-256-GCM.
- Clé maître : variable d’environnement ou secret serveur (hors dépôt Git).
- Aucune valeur en clair dans
llx_knot_*exposée à l’UI.
🔐 Types courants
| Type | Exemple |
|---|---|
| AI provider | Clé OpenAI / Anthropic |
| HTTP Bearer | Token API SaaS |
| Basic auth | Couple user/pass partenaire |
| Webhook secret | HMAC entrant |
Référence les credentials par ID dans les nodes ; l’export .knot.json ne contient pas les secrets.
🔐 Rotation
- Crée un nouveau credential avec la clé fraîche.
- Mets à jour chaque node concerné.
- Simulate puis run manuel de contrôle.
- Révoque l’ancienne clé chez le fournisseur.
- Supprime l’ancien credential Knot.
Pour un secret webhook exposé, régénère aussi l’URL si ton processus l’exige.
🔐 Bonnes pratiques
- Principe du moindre privilège sur les tokens API.
- Pas de secret dans les tickets, e-mails ou captures d’écran doc.
- Sépare prod / recette (deux credentials, deux instances).
🔐 Audit log
Consulte le journal d’audit pour :
- création / modification / suppression de credential ;
- qui a activé un workflow utilisant un secret ;
- corrélation avec un run Failed (sans fuite du secret dans le message).
Les logs applicatifs Knot masquent les en-têtes sensibles (SecretMasker côté produit).