Belajar n8n - Security & Credential Management

#Pendahuluan

Di episode 11 kalian mengotomatisasi file dan media: S3, Google Drive, FTP, hingga manipulasi dokumen dan gambar. Semua integrasi itu bersandar pada satu hal yang sama — kredensial. API key, token OAuth, dan password database adalah bahan bakar setiap workflow, dan justru itulah yang paling dicari penyerang. Sebuah instance yang integrasinya lengkap tapi kredensialnya bocor sama saja memberi kunci gudang kepada orang lain.

Episode 12 membahas Security & Credential Management. Roadmap-nya tiga: cara n8n menyimpan credential sensitif secara aman, cara mengelola environment variables dan secrets, lalu praktik terbaik untuk mengunci akses UI dan API.

#Kredensial: Target Utama Penyerang

Ketika kalian menambahkan kredensial di node — katakanlah API key layanan email dari episode 8 — n8n tidak menyimpannya sebagai teks polos. Nilai kredensial dienkripsi lalu disimpan di database, dan yang tertulis di node hanyalah referensi ke kredensial tersebut.

Inilah properti keamanan yang sering terlewat: nilai kredensial tidak pernah menjadi bagian dari JSON workflow maupun output node. Kredensial diterapkan secara internal ke request, lalu dihapus dari aliran data. Akibatnya, saat kalian mengekspor workflow atau memeriksa execution history, isi token tidak pernah terlihat. Bandingkan dengan menempel token langsung ke parameter node — nilai itu akan tercetak permanen di parameter dan membocorkannya ke riwayat eksekusi serta setiap ekspor workflow.

#Enkripsi Kredensial dengan Kunci Enkripsi

Kunci keamanan kredensial n8n adalah encryption key. Saat pertama kali dijalankan, n8n membuat kunci acak otomatis — tapi untuk produksi, kalian wajib menetapkannya sendiri lewat variabel lingkungan N8N_ENCRYPTION_KEY. Kunci ini menurunkan ciphertext untuk seluruh credential di database.

N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
N8N_USER_MANAGEMENT_JWT_SECRET=$(openssl rand -hex 32)

Dua hal yang harus kalian pegang teguh:

• Kunci harus stabil. Begitu kunci berubah, semua credential yang tersimpan tidak bisa didekripsi lagi — workflow yang bergantung padanya langsung gagal.
• Kunci harus dicadangkan terpisah dari database. Kalau database hilang tapi kunci aman, kalian masih bisa restore. Kalau kunci hilang, data kredensial selamanya menjadi sampah.

Simpan kunci di vault atau secret store infrastruktur, bukan di dalam repo. Untuk self-hosted yang memakai Docker, injeksi lewat Docker secrets atau Kubernetes secrets.

#Menyimpan Credential Sensitif secara Aman

Cara paling aman menyimpan rahasia integrasi di n8n adalah memakai credential entity yang tersedia di banyak node. Saat menuliskan credential custom — misalnya header auth untuk HTTP Request — tipe field yang menandai rahasia adalah password type, sehingga nilai ditampilkan sebagai bintang dan tidak masuk ke ekspor.

Lapisan kedua adalah menjaga env access di dalam node. Sejak versi 2.0, variabel lingkungan N8N_BLOCK_ENV_ACCESS_IN_NODE default-nya true, artinya ekspresi yang membaca $env dan fungsi di Code node tidak lagi melihat environment kalian. Ini disengaja: membaca env dari dalam workflow adalah celah bocor rahasia yang paling umum.

N8N_BLOCK_ENV_ACCESS_IN_NODE=true
NODE_FUNCTION_ALLOW_BUILTIN=*
NODE_FUNCTION_ALLOW_EXTERNAL=axios,lodash

Jika kalian benar-benar butuh nilai non-rahasia dari environment (base URL yang berbeda per environment), tetap boleh membuka akses — tapi batasi nilai yang dikonsumsi, dan jangan pernah menggunakannya untuk token. Untuk config antar environment yang tidak sensitif, variabel $vars juga bisa dipakai, asal bukan untuk rahasia.

#External Secrets Manager

Untuk skala tim atau enterprise, menyimpan rahasia di dalam database n8n bukan pilihan paling baik. n8n mendukung external secrets manager yang ditarik langsung saat runtime. Provider yang didukung: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Infisical, dan 1Password Connect Server.

Alurnya: buka Settings → External Secrets, tambahkan vault dengan nama unik, lalu pilih provider dan isi kredensial koneksinya. Setelah tersambung, setiap field credential bisa mereferensikan secret memakai expression — nama vault menjadi segmen pertama:

{
  "provider": "infisical",
  "vaultName": "prod-infisical",
  "credentialField": "DB_PASSWORD",
  "expression": "{{ $secrets.prod-infisical.DB_PASSWORD }}"
}

n8n menyegarkan cache secret secara berkala melalui N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL (default 300 detik). Nilai secret baru otomatis tersedia di eksekusi berikutnya tanpa restart instance. Catatan penting: fitur ini berlisensi enterprise pada n8n, jadi pastikan lisensi kalian mendukungnya sebelum berencana menggunakannya.

#Mengunci Akses UI

Akses ke editor UI adalah akses ke semua workflow dan kredensial. Melindunginya adalah prioritas tertinggi:

• User management aktif. Pastikan instance memakai login dengan akun, bukan mode tanpa autentikasi. Gunakan role owner untuk administrasi, dan beri anggota hanya hak yang dibutuhkan — detail role akan kita bedah di episode 14.
• Tutup UI bila tidak diperlukan. Instances yang semata-mata mengeksekusi workflow bisa mematikan antarmuka dengan N8N_DISABLE_UI=true, sehingga tidak ada permukaan serangan editor.
• Reverse proxy dengan HTTPS. Jangan pernah memaparkan UI ke internet tanpa TLS. Taruh n8n di belakang reverse proxy yang mengakhiri TLS dan menangani rate limiting.
• SSO untuk organisasi. n8n enterprise mendukung SAML dan OAuth2, jadi kredensial login mengikuti kebijakan identitas perusahaan.

#Mengunci Akses API

Selain UI, n8n membuka Public REST API untuk integrasi eksternal. API ini dilindungi API key yang dikelola di Settings → API. Setiap request wajib membawa header X-N8N-API-KEY.

curl -s https://n8n.example.com/api/v1/workflows \
  -H "X-N8N-API-KEY: n8n_api_xxxxxxxxxxxx"

Beberapa titik yang wajib dirawat:

• Rotasi API key secara berkala, terutama jika pernah tersebar ke log atau email.
• Jangan memaparkan endpoint /metrics ke publik. Endpoint ini mengungkap data operasional — biarkan hanya diakses jaringan internal monitoring.
• Webhook perlu autentikasi sendiri. Sesuai episode 5 dan 9, atur header auth atau token pada trigger webhook agar endpoint tidak bisa dipicu sembarangan.
• Batasi jaringan. Pada self-hosted, gunakan firewall atau network policy agar port 5678 dan 5679 hanya diakses dari jaringan tepercaya.

#Checklist Keamanan

Merangkum semua langkah di atas menjadi daftar periksa singkat:

• N8N_ENCRYPTION_KEY ditetapkan eksplisit, stabil, dan dicadangkan terpisah.
• Kredensial integrasi tersimpan sebagai credential entity, bukan nilai mentah di parameter.
• Akses $env di node dibiarkan terkunci (N8N_BLOCK_ENV_ACCESS_IN_NODE=true).
• Secret production dipindah ke external secrets manager bila memungkinkan.
• UI hanya bisa diakses dengan akun dan HTTPS; matikan UI bila tidak dibutuhkan.
• API key dirotasi dan endpoint /metrics tersembunyi dari publik.
• Webhook dilindungi token, dan port hanya terbuka untuk jaringan tepercaya.

#Penutup

Episode 12 menutup celah yang paling sering dieksploitasi: kredensial. Kalian memahami bahwa nilai kredensial tersimpan terenkripsi dan tidak pernah bocor ke JSON workflow, pentingnya menetapkan dan mencadangkan N8N_ENCRYPTION_KEY, cara mengelola environment variables serta memindahkan rahasia ke external secrets manager, dan langkah mengunci akses UI serta API.

Inti yang harus dibawa pulang:

• Credential disimpan terenkripsi dan direferensikan, nilainya tidak pernah masuk ke ekspor maupun output node.
• N8N_ENCRYPTION_KEY harus eksplisit, stabil, dan dicadangkan — kehilangannya berarti kehilangan seluruh kredensial.
• Jangan menginjeksi rahasia lewat $env atau $vars karena nilainya mengalir ke execution data.
• External secrets manager memusatkan rahasia di vault dan menyegarkannya otomatis (fitur enterprise).
• Akses UI dan API dikunci dengan user management, HTTPS, API key yang dirotasi, dan endpoint monitoring yang tersembunyi.

Di episode 13 berikutnya kita belajar memantau apa yang terjadi di instance: Audit, Monitoring & Observability — melacak eksekusi workflow dan node logs, mengintegrasikan Prometheus, Grafana, dan ELK, serta menerapkan alert untuk failure. Sampai jumpa!