n8n credential'ları nasıl şifreler, ekipte kimler paylaşabilir ve External Secrets erişim verilerini n8n dışında nasıl yönetir.
Kimlik bilgileri (credentials), her n8n otomasyonunun asıl temelidir: API anahtarı, OAuth2 token'ı veya veritabanı şifresi olmadan hiçbir dijital çalışan dış sistemlerle iletişim kuramaz. Tam da bu yüzden n8n'in bu credential'ları gerçekte nasıl koruduğuna, ekipte kimlerin bunları görmeden kullanabildiğine ve hassas değerlerin harici bir secrets store tarafından yönetilerek n8n'in tamamen dışında nasıl tutulabildiğine yakından bakmakta fayda var. Durum: Temmuz 2026.
Bu yazı üç katmanı net bir şekilde birbirinden ayırır: arka planda çalışan şifreleme modeli, ekipler için paylaşım hakları ve kurumsal (enterprise) kurulumlar için harici secret store entegrasyonu. Sonunda, kurulumunuz için hangi katmanın doğru olduğu konusunda kontrol sizde olacak.
n8n tüm kimlik bilgilerini her zaman veritabanında şifreli olarak saklar, asla açık metin olarak değil. kendi şifreleme anahtarınızı belirleme kılavuzuna göre n8n ilk başlatmada otomatik olarak rastgele bir anahtar oluşturur ve bunu `~/.n8n` klasöründe saklar. n8n, veritabanına yazmadan önce her credential'ı bu anahtarla şifreler. Bu anahtarın kontrolünü kendiniz elinizde tutmak isterseniz, örneğin merkezi olarak yönetmek veya dosya sisteminden bağımsız bir yedek oluşturmak için başlatmadan önce şu ortam değişkenini ayarlayın:
```
export N8N_ENCRYPTION_KEY=<rastgele, uzun bir dize>
```
Ekip ve üretim ortamında önemli bir nokta: n8n birden fazla worker ile queue modunda çalışıyorsa tüm instance'lar `N8N_ENCRYPTION_KEY` için tam olarak aynı değeri kullanmalıdır. Aksi takdirde worker'lar, ana süreç tarafından şifrelenen kimlik bilgilerinin şifresini çözemez ve workflow'lar tam olarak bir credential'a ihtiyaç duyulan noktada hataya düşer.
Self-hosted instance'lar için n8n ayrıca şifreleme rotasyonu da sunar. şifreleme anahtarı rotasyonu dokümantasyonuna göre n8n bunu yaparken iki katmanla çalışır:
Zaten şifrelenmiş veriler bir rotasyondan sonra okunabilir kalır; n8n bunları gelecekteki yazma işlemlerinde otomatik olarak yeni Data Encryption Key ile yeniden şifreler. Özellik, tüm instance'larda `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` ortam değişkeni üzerinden etkinleştirilir, ardından rotasyon Settings > Data Encryption Keys altında arayüzden veya API üzerinden (`POST /encryption/keys`) tetiklenebilir. Önceden mutlaka bilmeniz gereken bir nokta: özellik etkinleştirildikten ve yeni formatta veri yazıldıktan sonra rotasyon geri alınamaz ve verileri eski formata geri dönüştürmek için herhangi bir otomatik araç bulunmaz. Bu nedenle etkinleştirmeden önce eksiksiz bir veritabanı yedeği alınması bir tercih değil, zorunluluktur.
Birden fazla kişi aynı workflow'lar üzerinde çalışmaya başladığında, kimin hangi kimlik bilgilerini görebileceği ve kullanabileceği sorusu ortaya çıkar. n8n burada bir credential'ın kullanımı ile değerlerine erişimi bilinçli olarak birbirinden ayırır. workflow paylaşımı dokümantasyonuna göre şu kural geçerlidir: bir workflow'u paylaşan kişi, açıkça tek tek paylaşılmamış olsa bile, içinde kullanılan tüm credential'lara erişimi de otomatik olarak paylaşmış olur. Bu, paylaşılan workflow'ların ilgili herkes için gerçekten çalışabilir kalmasını sağlar.
Rollere gelince, n8n iki seviye arasında ayrım yapar:
En az yetki ilkesi burada da tutarlı bir şekilde geçerlidir: workflow'da kullanılan bir credential ayrıca tek tek paylaşılmamışsa, bir Editor workflow'u çalıştırabilir ve diğer node'ları düzenleyebilir, ancak paylaşılmamış credential'a sahip node'u değiştiremez. Paylaşılan bir credential'ın değerleri, yani API anahtarları veya şifreler, Editor'lar için temelde görünmez kalır. Credential'ı kullanabilirler ama içeriğini okuyamazlar. Önemli bir pratik not: bir workflow'un sahipliği, bir kullanıcı hesabının silinmesi durumu dışında basitçe devredilemez. Bu nedenle baştan itibaren ekip halinde çalışanların, workflow'ları kişisel çalışma alanı yerine mümkünse doğrudan ortak bir projede oluşturması önerilir, çünkü dokümantasyona göre "Add users" işlevi üzerinden tek tek kullanıcı ekleme yalnızca kişisel alandaki workflow'lar için çalışır. Bir proje içindeki workflow'larda ise yetkilendirme bunun yerine proje üyeliği üzerinden yapılır.
Kurumsal (enterprise) kurulumlar için n8n bir adım daha ileri gider ve hassas değerlerin n8n'in kendisinde hiç saklanmaması, bunun yerine harici bir secrets store'da tutulması imkânını sunar. harici secret store dokümantasyonuna göre n8n bunun için altı sağlayıcıyı destekler:
Bu özellik Enterprise Self-hosted ve Enterprise Cloud planlarına bağlıdır. Bir vault, Settings > External Secrets altında "Add secrets vault" üzerinden kurulur: burada vault için benzersiz bir ad verir, sağlayıcıyı seçer ve bunun için gereken kimlik bilgilerini girersiniz. Bir credential içinde, ardından harici değere bir ifade (expression) üzerinden erişirsiniz, örneğin:
```
{{ $secrets.<vault-name>.<secret-name> }}
```
1Password için öğe başlığı ve alan etiketiyle genişletilmiş bir söz dizimi vardır: `{{ $secrets.<vault-name>.<item-title>.<field-label> }}`. Bilmeniz gereken teknik bir sınırlama şudur: n8n, secret'lar için yalnızca basit metin değerlerini destekler, JSON nesnelerini desteklemez ve ifadeler yalnızca credential alanları içinde çalışır, expression desteği olan diğer alanlarda çalışmaz. Buna karşılık `N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL` ortam değişkeni ile n8n'in harici store'daki değişiklikleri ne sıklıkla kontrol edeceği belirlenebilir, varsayılan olarak her 300 saniyede bir.
Küçük ekipler için pratikte genellikle düzgün ayarlanmış bir `N8N_ENCRYPTION_KEY`, iyi düşünülmüş proje ve paylaşım yapılarıyla birleştiğinde zaten yeterlidir: kimin hangi workflow'u görebileceği, otomatik olarak kimin hangi credential'ı kullanabileceğini de belirler. Ancak staging ve production gibi birden fazla ortam aynı API erişimlerine ihtiyaç duyduğunda veya bir uyumluluk (compliance) gereksinimi, sırların merkezi olarak bir vault'ta tutulmasını ve orada da merkezi olarak rotasyona tabi tutulmasını talep ettiğinde, External Secrets mantıklı bir tamamlayıcı hâline gelir. İki katman birbirini dışlamaz ve birleştirilebilir: veritabanı şifrelemesi n8n'in kendisinin sakladığı şeyi korur, External Secrets ise n8n'in kalıcı olarak saklamak zorunda kaldığı şeyi ayrıca azaltır.
Bir ekip için n8n instance'ı kurmak ve bu sırada şifrelemeyi, yetkilendirmeyi ve gerektiğinde harici secret store'ları baştan itibaren düzgün planlamak isteyenler, hassas kimlik bilgilerinin en başından itibaren ait oldukları yerde durması için NordFlux'un n8n otomasyonları ile destek bulur.
Varsayılan olarak n8n, ilk başlatmada rastgele oluşturulan anahtarı `~/.n8n` klasöründe saklar ve veritabanına kaydetmeden önce credential'ları şifrelemek için kullanır. Anahtarı kendiniz belirlemek isterseniz, ilk başlatmadan önce `N8N_ENCRYPTION_KEY` ortam değişkenini ayarlayın.
Evet, standart durum tam olarak budur. Bir credential bir kullanıcıyla veya bir proje üzerinden paylaşıldığında, bu kişi credential'ı kendi workflow'larında kullanabilir; ancak API anahtarları veya şifreler gibi asıl değerler gizli kalır.
Bir workflow paylaşıldığında, davet edilen kişi yine de onu tam olarak çalıştırabilir, çünkü workflow paylaşımı içerdiği tüm credential'ların kullanımını otomatik olarak kapsar. Ancak ilgili node yalnızca credential ayrıca tek tek paylaşılmışsa düzenlenebilir; workflow'daki diğer tüm node'lar bundan etkilenmez.
Hayır. Dokümantasyona göre External Secrets yalnızca Enterprise Self-hosted ve Enterprise Cloud planlarında kullanılabilir. Şu anda altı sağlayıcı desteklenmektedir: 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault ve Infisical.
Hayır. Anahtar rotasyonu etkinleştirildikten ve n8n veriyi yeni formatta yazdıktan sonra özellik artık devre dışı bırakılamaz ve eski formata geri dönmek için herhangi bir otomatik araç yoktur. Bu nedenle etkinleştirmeden önce eksiksiz bir veritabanı yedeği alınması kesinlikle önerilir.
NordFlux, kuruluşlar için dijital çalışanlar kurar: tekrar eden işleri üstlenen otomasyonlar ve KI ajanları. Kontrol sizde kalır.
n8n nasıl sıkılaştırılır: 2FA'yı etkinleştirin, SSRF korumasını kurun, riskli nodeları NODES_EXCLUDE ile kilitleyin ve kullanılmıyorsa Public API'yi devre dışı bırakın.
n8n şifreleme anahtarını kaybederseniz, kayıtlı tüm kimlik bilgileri kullanılamaz hale gelir. İş akışlarını, kimlik bilgilerini ve anahtarları doğru şekilde nasıl yedekleyeceğiniz burada.
n8n'de Anthropic ve OpenAI kimlik bilgilerini nasıl kuracağınız, her görev için doğru modeli nasıl seçeceğiniz ve token maliyetlerini nasıl kontrol altında tutacağınız.
Ekip içinde paylaşım çok geniş tutulduğunda veya External Secrets kullanılmadığında, şifreleme tek başına yeterli korumayı sağlamaz. NordFlux, n8n kurulumunuzun yetki modelini inceler ve ekip büyüklüğünüze ve uyumluluk gereksinimlerinize uygun bir credential yönetimi kurar. İlk görüşmede mevcut yapılandırmanızı birlikte gözden geçiririz.
