Credentials sicher verwalten: Verschlüsselung, Sharing, External Secrets

Zugangsdaten sind das eigentliche Herzstück jeder n8n-Automatisierung: Ohne API-Schlüssel, OAuth2-Token oder Datenbank-Passwort kann kein digitaler Mitarbeiter mit externen Systemen sprechen. Genau deshalb lohnt sich ein genauer Blick darauf, wie n8n diese Credentials tatsächlich schützt, wer sie im Team nutzen darf, ohne sie zu sehen, und wie sich sensible Werte ganz aus n8n heraushalten lassen, indem ein externer Secrets-Store sie verwaltet. Stand: Juli 2026.

Dieser Beitrag ordnet drei Ebenen sauber voneinander ab: das Verschlüsselungsmodell im Hintergrund, die Sharing-Rechte für Teams und die Anbindung externer Secret-Stores für Enterprise-Setups. Du behältst am Ende die Kontrolle darüber, welche Ebene für dein Setup die richtige ist.

Wie n8n Credentials verschlüsselt

n8n speichert alle Zugangsdaten grundsätzlich verschlüsselt in der Datenbank, nie im Klartext. Laut der Anleitung zum eigenen Verschlüsselungsschlüssel erzeugt n8n beim ersten Start automatisch einen zufälligen Schlüssel und legt ihn im Ordner `~/.n8n` ab. Mit diesem Schlüssel verschlüsselt n8n jede Credential, bevor sie in die Datenbank geschrieben wird. Wer die Kontrolle über diesen Schlüssel selbst behalten möchte, etwa um ihn zentral zu verwalten oder ein Backup unabhängig vom Dateisystem anzulegen, setzt vor dem Start die Umgebungsvariable:

```

export N8N_ENCRYPTION_KEY=<ein zufälliger, langer String>

```

Wichtig im Team- und Produktivbetrieb: Läuft n8n im Queue-Modus mit mehreren Workern, müssen alle Instanzen exakt denselben Wert für `N8N_ENCRYPTION_KEY` verwenden. Sonst können Worker die vom Hauptprozess verschlüsselten Zugangsdaten nicht entschlüsseln, und Workflows schlagen an genau der Stelle fehl, an der eine Credential gebraucht wird.

Zwei-Schichten-Modell mit Schlüsselrotation

Für Self-hosted-Instanzen bietet n8n zusätzlich eine Rotation der Verschlüsselung an. Laut der Dokumentation zur Rotation von Verschlüsselungsschlüsseln arbeitet n8n dabei mit zwei Ebenen:

• Instance Encryption Key (`N8N_ENCRYPTION_KEY`): der dauerhafte Master-Schlüssel, der sich nicht ändert.
• Data Encryption Key: der eigentliche Schlüssel, der Credentials und andere sensible Daten verschlüsselt und sich rotieren lässt, ohne den Master-Schlüssel anzufassen.

Bereits verschlüsselte Daten bleiben nach einer Rotation lesbar, n8n verschlüsselt sie bei künftigen Schreibvorgängen automatisch mit dem neuen Data Encryption Key nach. Aktiviert wird die Funktion über die Umgebungsvariable `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` auf allen Instanzen, danach lässt sich die Rotation unter Settings > Data Encryption Keys in der Oberfläche oder per API (`POST /encryption/keys`) auslösen. Ein Punkt, den man vorher unbedingt verinnerlichen sollte: Sobald die Funktion aktiv ist und neue Daten im neuen Format geschrieben wurden, lässt sich die Rotation nicht mehr rückgängig machen und es existiert kein automatisiertes Werkzeug, um Daten zurückzukonvertieren. Ein vollständiges Datenbank-Backup vor der Aktivierung ist deshalb keine Kür, sondern Pflicht.

Credentials im Team teilen, ohne sie preiszugeben

Sobald mehrere Personen an denselben Workflows arbeiten, stellt sich die Frage, wer welche Zugangsdaten sehen und nutzen darf. n8n trennt hier bewusst zwischen der Nutzung einer Credential und dem Einblick in ihre Werte. Laut der Dokumentation zum Teilen von Workflows gilt: Wer einen Workflow teilt, teilt automatisch auch den Zugriff auf alle darin verwendeten Credentials mit, selbst wenn diese nicht explizit einzeln freigegeben wurden. Das sorgt dafür, dass geteilte Workflows für alle Beteiligten tatsächlich lauffähig bleiben.

Bei den Rollen unterscheidet n8n zwischen zwei Stufen:

• Creator (die ursprüngliche Person, die den Workflow angelegt hat): darf den Workflow ansehen, ausführen, bearbeiten, exportieren, freigeben und löschen.
• Editor (Personen mit geteiltem Zugriff): darf ansehen, ausführen, bearbeiten und exportieren, aber weder freigeben noch löschen.

Das Prinzip der geringsten Rechte gilt konsequent weiter: Ist eine im Workflow verwendete Credential nicht zusätzlich einzeln freigegeben, kann ein Editor zwar den Workflow ausführen und andere Nodes bearbeiten, aber genau den Node mit der ungeteilten Credential nicht verändern. Die Werte einer geteilten Credential, also API-Schlüssel oder Passwörter, bleiben für Editoren dabei grundsätzlich unsichtbar. Sie können die Credential nutzen, aber nicht auslesen. Ein wichtiger Praxishinweis am Rand: Der Besitz eines Workflows lässt sich nicht einfach übertragen, außer im Zuge der Löschung eines Nutzerkontos. Wer also von Anfang an im Team arbeitet, sollte Workflows möglichst direkt in einem gemeinsamen Projekt statt im persönlichen Arbeitsbereich anlegen, denn das Hinzufügen einzelner Nutzer über die "Add users"-Funktion funktioniert laut Dokumentation nur für Workflows im persönlichen Bereich. Bei Workflows innerhalb eines Projekts erfolgt die Rechtevergabe stattdessen über die Projektmitgliedschaft selbst.

External Secrets: Zugangsdaten außerhalb von n8n verwalten

Für Enterprise-Setups geht n8n noch einen Schritt weiter und erlaubt es, sensible Werte gar nicht erst in n8n selbst zu speichern, sondern in einem externen Secrets-Store zu belassen. Laut der Dokumentation zu externen Secret-Stores unterstützt n8n dafür sechs Anbieter:

• 1Password (über den Connect Server)
• AWS Secrets Manager
• Azure Key Vault
• GCP Secrets Manager
• HashiCorp Vault
• Infisical

Diese Funktion ist an Enterprise Self-hosted- und Enterprise-Cloud-Pläne gebunden. Eingerichtet wird ein Vault unter Settings > External Secrets über "Add secrets vault": Dort vergibst du einen eindeutigen Namen für den Vault, wählst den Anbieter aus und trägst die dafür nötigen Zugangsdaten ein. Innerhalb einer Credential greifst du anschließend per Ausdruck auf den externen Wert zu, zum Beispiel:

```

{{ $secrets.<vault-name>.<secret-name> }}

```

Für 1Password gibt es eine erweiterte Syntax mit Item-Titel und Feldbezeichnung: `{{ $secrets.<vault-name>.<item-title>.<field-label> }}`. Eine technische Einschränkung sollte man kennen: n8n unterstützt für Secrets ausschließlich einfache Textwerte, keine JSON-Objekte, und die Ausdrücke funktionieren nur innerhalb von Credential-Feldern, nicht in anderen Feldern mit Expression-Unterstützung. Dafür lässt sich über die Umgebungsvariable `N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL` festlegen, wie oft n8n auf Änderungen im externen Store prüft, standardmäßig alle 300 Sekunden.

Welches Modell für welches Setup passt

Für kleinere Teams reicht in der Praxis oft schon ein sauber gesetzter `N8N_ENCRYPTION_KEY` in Kombination mit durchdachten Projekt- und Sharing-Strukturen: Wer welchen Workflow sehen darf, entscheidet automatisch mit, wer welche Credential nutzen kann. Sobald aber mehrere Umgebungen, etwa Staging und Produktion, dieselben API-Zugänge benötigen oder eine Compliance-Vorgabe verlangt, dass Geheimnisse zentral in einem Vault liegen und dort auch zentral rotiert werden, wird External Secrets zur sinnvollen Ergänzung. Beide Ebenen schließen sich nicht aus und lassen sich kombinieren: die Datenbank-Verschlüsselung schützt, was n8n selbst speichert, External Secrets reduziert zusätzlich, was n8n überhaupt erst dauerhaft speichern muss.

Wer eine n8n-Instanz für ein Team aufsetzen und dabei Verschlüsselung, Rechtevergabe und gegebenenfalls externe Secret-Stores von Anfang an sauber planen möchte, findet bei den n8n-Automatisierungen von NordFlux Unterstützung, damit sensible Zugangsdaten von Beginn an dort liegen, wo sie hingehören.

Häufige Fragen

Wo speichert n8n den automatisch generierten Verschlüsselungsschlüssel?

Standardmäßig legt n8n den beim ersten Start zufällig erzeugten Schlüssel im Ordner `~/.n8n` ab und nutzt ihn, um Credentials vor dem Speichern in der Datenbank zu verschlüsseln. Wer den Schlüssel selbst festlegen möchte, setzt vor dem ersten Start die Umgebungsvariable `N8N_ENCRYPTION_KEY`.

Kann ich eine Credential teilen, ohne dass andere den API-Schlüssel sehen?

Ja, genau das ist der Standardfall. Wird eine Credential mit einem Nutzer oder über ein Projekt geteilt, kann diese Person die Credential in eigenen Workflows verwenden, die eigentlichen Werte wie API-Schlüssel oder Passwörter bleiben dabei jedoch verborgen.

Was passiert, wenn eine im Workflow verwendete Credential nicht extra freigegeben wurde?

Wird ein Workflow geteilt, kann die eingeladene Person ihn trotzdem vollständig ausführen, da Workflow-Sharing automatisch die Nutzung aller enthaltenen Credentials einschließt. Bearbeiten lässt sich der betroffene Node aber nur, wenn die Credential zusätzlich einzeln geteilt wurde, alle anderen Nodes des Workflows bleiben davon unberührt.

Ist External Secrets in jedem n8n-Plan verfügbar?

Nein. External Secrets steht laut Dokumentation nur auf Enterprise Self-hosted- und Enterprise-Cloud-Plänen zur Verfügung. Unterstützt werden aktuell sechs Anbieter: 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault und Infisical.

Lässt sich die Rotation des Verschlüsselungsschlüssels rückgängig machen?

Nein. Sobald die Schlüsselrotation aktiviert ist und n8n Daten im neuen Format geschrieben hat, lässt sich die Funktion nicht mehr deaktivieren und es gibt kein automatisiertes Werkzeug, um zum alten Format zurückzukehren. Ein vollständiges Datenbank-Backup vor der Aktivierung ist deshalb dringend zu empfehlen.