External Secrets dans n8n : connecter Vault, AWS Secrets Manager et Azure Key Vault

Une clé API OpenAI, un token Stripe, un mot de passe de base de données : notre guide sur la sécurisation des credentials n8n explique comment n8n les chiffre par défaut avec la N8N_ENCRYPTION_KEY de l'instance, et pourquoi ce système suffit à la plupart des équipes. Mais dès qu'une organisation gère plusieurs instances n8n (dev, staging, prod, ou plusieurs clients en agence), la question change de nature : le secret « source de vérité » vit déjà ailleurs — dans un coffre-fort d'entreprise avec sa propre politique de rotation, ses propres logs d'accès, son propre audit de conformité — et le dupliquer credential par credential dans chaque instance n8n devient vite le maillon qu'on oublie de faire tourner. C'est exactement le problème qu'External Secrets résout : brancher n8n directement sur ce coffre-fort externe, sans jamais stocker la valeur du secret dans n8n lui-même.

Ce n'est pas une précaution théorique. Une étude de Meli, McNiece et Reaves présentée au NDSS Symposium en 2019 a scanné des centaines de milliers de dépôts GitHub publics et y a trouvé des centaines de milliers de secrets valides — clés API, identifiants de bases de données, tokens cloud — committés en clair, souvent parce qu'un développeur pressé les avait recopiés directement dans un fichier de configuration plutôt que de les référencer depuis un système centralisé (Meli, McNiece & Reaves, How Bad Can It Git?, NDSS 2019). Le risque avec plusieurs instances n8n est le même en modèle réduit : chaque copie manuelle d'une clé API dans un nouveau credential est une occasion de plus de la laisser traîner dans un export JSON partagé, une capture d'écran de support ou une sauvegarde mal protégée.

Ce qu'External Secrets fait — et pour qui

External Secrets est une fonctionnalité Enterprise, aussi bien sur n8n Cloud qu'en self-hosted : elle n'existe pas sur l'édition Community gratuite. Une fois activée, elle permet de déclarer un ou plusieurs « vaults » (coffres-forts) externes dans Settings, puis de référencer leurs secrets depuis n'importe quel champ de credential n8n, sans jamais saisir la valeur réelle dans l'interface. n8n ne fait que lire ces secrets à intervalle régulier ; il ne les écrit ni ne les modifie jamais côté fournisseur.

Les fournisseurs supportés aujourd'hui sont AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault (self-hosted, Community ou Enterprise — pas l'offre SaaS HCP Vault Secrets, distincte malgré le nom proche), Infisical, et 1Password via un 1Password Connect Server auto-hébergé (une API d'accès machine, pas votre coffre-fort personnel 1Password).

Configurer un vault

Toute la configuration se fait depuis l'UI, dans Settings > External Secrets > Add secrets vault — il n'existe pas d'équivalent en variable d'environnement pour déclarer un vault lui-même. Pour HashiCorp Vault par exemple, n8n demande :

• l'URL du serveur Vault ;
• la méthode d'authentification : Token, AppRole ou Userpass ;
• un namespace optionnel (pertinent pour un Vault Enterprise multi-tenants) ;
• un chemin de mount KV en saisie manuelle, utile quand le token fourni n'a pas le droit sys/mounts nécessaire pour que n8n le détecte automatiquement.

Une fois le vault ajouté et validé, n8n liste les secrets qu'il y trouve — sans jamais en afficher la valeur en clair dans l'interface, seulement leur nom.

Utiliser un secret dans un credential

Le secret ne s'utilise pas n'importe où : uniquement dans un champ de credential n8n, basculé en mode expression, avec la syntaxe {{ $secrets.<nom-du-vault>.<nom-du-secret> }}. Pour un credential API Key classique, ça donne par exemple {{ $secrets.vault-prod.stripe-secret-key }} dans le champ qui attendrait normalement la clé Stripe en clair. Pour 1Password, la syntaxe intègre un niveau supplémentaire — item puis champ — soit {{ $secrets.<vault>.<titre-item>.<libelle-champ> }}.

C'est une limite structurelle à connaître avant de construire un montage dessus : cette syntaxe ne fonctionne que dans les champs de credentials. Elle échoue silencieusement (ou n'est simplement pas résolue) dans un node Code, dans un champ Set ou dans n'importe quel paramètre standard d'un node. Pour faire circuler une valeur externe ailleurs dans la logique d'un workflow, il faut passer par un credential dédié attaché à un node qui sait l'exploiter — typiquement un HTTP Request avec une authentification générique (Header Auth, Query Auth) pointant vers ce credential.

Rafraîchissement, permissions et organisation multi-projets

n8n ne relit pas le fournisseur externe à chaque exécution de workflow : il interroge chaque vault à intervalle régulier, 300 secondes par défaut, ajustable via la variable d'environnement N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL (voir notre guide sur les variables d'environnement n8n pour le reste des réglages de ce type). Ce cache a une conséquence opérationnelle directe : après une rotation d'urgence côté fournisseur, l'ancienne valeur reste utilisable côté n8n jusqu'au prochain cycle, sauf resynchronisation manuelle du vault depuis Settings. Un point à intégrer dans toute procédure de révocation de clé compromise plutôt qu'à découvrir le jour où elle sert.

Côté permissions, l'accès aux vaults se gère par un rôle dédié (« sync vaults » dans Settings > Roles), distinct des permissions classiques sur les workflows. Les versions récentes ajoutent la possibilité de déclarer plusieurs vaults pour un même fournisseur (utile pour séparer les secrets de plusieurs clients sur une même instance — un cas de figure que couvre notre guide sur l'hébergement n8n pour plusieurs clients), ainsi que des vaults scopés à un projet n8n plutôt qu'à l'instance entière, avec un accès en lecture ou administration réservé aux rôles projet concernés — une évolution pensée précisément pour les organisations qui séparent déjà leurs environnements ou leurs clients par projet.

Ce qu'External Secrets ne remplace pas

Deux confusions reviennent souvent :

• Ce n'est pas un substitut à la N8N_ENCRYPTION_KEY : cette clé continue de chiffrer les credentials n8n eux-mêmes, y compris ceux qui référencent un secret externe. Perdre cette clé reste aussi problématique qu'avant, comme détaillé dans notre guide sur les credentials n8n.
• Ce n'est pas un mécanisme d'injection dans le corps d'un workflow : seules des chaînes de caractères en clair sont supportées (pas d'objet JSON structuré), et uniquement dans un champ de credential. Un besoin d'accéder à une configuration complexe stockée dans un secrets manager appelle un appel HTTP direct à l'API du fournisseur, pas External Secrets.

Est-ce vraiment nécessaire pour votre instance ?

Pour une instance n8n unique, gérée par une petite équipe, le système de credentials chiffrés natif de n8n — bien utilisé, avec permissions par équipe et rotation manuelle documentée — couvre l'essentiel sans justifier une licence Enterprise ni la charge de maintenir un Vault ou un compte AWS Secrets Manager en plus. External Secrets prend tout son sens dans deux cas concrets : une organisation qui gère déjà une politique de rotation automatisée à l'échelle de toute son infrastructure (pas seulement pour n8n) et veut simplement y brancher un système de plus, ou une agence qui héberge plusieurs clients sur des instances n8n séparées et veut centraliser la gestion des secrets sans les dupliquer manuellement à chaque nouveau client — un contexte qui recoupe directement les enjeux traités dans notre Pack Conformité & Audit (149 €), pensé pour les équipes qui doivent déjà documenter qui a accès à quoi et pourquoi. Si votre stack combine en plus des automatisations IA sensibles aux mêmes exigences de traçabilité, le Bundle FlowKit Complet (269 €) réunit ce pack avec les deux autres sur cette même base d'exigence.