Belajar n8n - Governance & Multi-user Collaboration

#Pendahuluan

Di episode 13 kalian memantau instance dengan execution data, metrik Prometheus, dan alert. Sekarang bayangkan instance yang sama dipakai tiga belas orang dari tiga tim berbeda. Tanpa aturan main, satu orang bisa mengubah workflow yang dipakai orang lain, atau membaca kredensial yang bukan haknya. Observability tidak menjawab masalah itu — yang dibutuhkan adalah tata kelola.

Episode 14 membahas Governance & Multi-user Collaboration: mengelola user access dan role-based permissions, berbagi workflow, credential, dan folder, serta menjaga change control dan audit trails.

#Model User & Role-Based Permissions

n8n membedakan hak akses pada dua tingkat. Pertama, tingkat instance, dengan tiga role utama:

• Owner — pemegang kendali penuh instance: mengelola user, lisensi, pengaturan, dan semua resource. Hanya satu yang berhak di posisi ini.
• Admin — mengelola user, pengaturan instance, dan resource bersama tanpa hak pengelolaan lisensi.
• Member — mengelola workflow dan resource miliknya sendiri; hanya mengakses hal yang dibagikan kepadanya.

Kedua, tingkat project. Sejak versi 1.x, n8n memperkenalkan projects sebagai wadah berbagi: setiap project punya kumpulan workflow dan credential, dan keanggotaannya menentukan siapa yang bisa bekerja di dalamnya. Di atas lapisan ini, RBAC memberi kontrol lebih halus — misalnya hak edit dibedakan dari hak sekadar melihat.

Model ini mengikuti prinsip least privilege: setiap orang mendapat hak serendah mungkin yang cukup untuk tugasnya. Owner tidak perlu ikut mengedit setiap workflow harian, dan member tidak perlu menyentuh pengaturan instance. Batas tegas antar role inilah yang mencegah insiden "satu orang menghapus semuanya".

#Mengelola User Access

Menambahkan anggota dilakukan lewat Settings → Users, lalu mengirim undangan lewat email. Peran yang dipilih menentukan batas kerja mereka. Untuk memastikan hanya orang yang tepat yang masuk, lengkapi dengan:

• MFA — autentikasi dua faktor untuk akun, mengurangi risiko kredensial login yang dicuri.
• SSO — integrasi SAML atau OAuth2 pada lisensi enterprise sehingga login mengikuti kebijakan identitas perusahaan.
• Provisioning CLI — saat bootstrapping instance, owner bisa menaikkan peran lewat command line sebelum UI diakses.

Contoh mempromosikan user pertama menjadi owner saat setup, lalu mengecek daftar user lewat Public API:

n8n user-management:promote --email=owner@example.com

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

Public API juga bisa dipakai untuk otomasi administrasi — misalnya skrip yang menjadwalkan rotasi akses, atau sync daftar user dari sistem HR. Pastikan API key yang dipakai khusus untuk tugas ini dan diberikan hak terbatas, sesuai pola keamanan yang kita bangun di episode 12.

Prinsip minimal: berikan role serendah mungkin, naikkan hanya saat dibutuhkan, dan audit perubahan role secara berkala. Saat seseorang pindah tim atau keluar perusahaan, segarkan aksesnya sesegera mungkin — akun lama yang terlupakan adalah pintu belakang yang umum dieksploitasi.

#Berbagi Workflow, Credential & Folder

Berbagi di n8n dilakukan per resource, bukan per instance. Setiap workflow bisa dibagikan:

• Ke semua user — cocok untuk workflow umum seperti error handler atau notifikasi.
• Ke project tertentu — workflow diorganisasi dalam project, dan anggota project mendapat akses sesuai perannya.

Folders melengkapi organisasi: workflow bisa dikelompokkan dalam folder di dalam project, sehingga ratusan workflow tidak menumpuk dalam satu daftar. Struktur yang disarankan untuk tim:

Project: Core-Ops
  ├── Folder: Triggers
  ├── Folder: Sync (database)
  └── Folder: Reports
Project: Marketing
  └── Folder: Campaigns

#Mengontrol Akses Credential

Credential adalah aset paling sensitif, sehingga aturan berbaginya lebih ketat. Saat membuat credential, kalian memilih proyek yang boleh menggunakannya. Anggota di luar project tidak bisa melihat, apalagi memakai, credential tersebut — bahkan bila mereka membuka workflow yang mereferensikannya.

Ini penting untuk dipahami saat berbagi workflow: workflow yang dibagikan tetap berjalan normal memakai credential milik pemiliknya, tetapi penerima tidak otomatis mendapat akses ke nilai kredensial. Bila perlu, pemilik membagikan credential ke project lain secara eksplisit. Nilai kredensial sendiri tidak pernah terlihat oleh siapa pun — hanya referensinya.

Kapan sebuah credential boleh dibagikan? Aturan praktisnya: bagikan hanya bila ada workflow yang benar-benar memakainya, dan batasi ke project terkecil yang membutuhkan. Hindari satu credential raksasa yang dipakai semua project — ketika service berubah, rotasi credential itu mengganggu seluruh instance sekaligus.

#Change Control

Workflow yang dipakai bersama berubah cepat; yang berbahaya adalah perubahan tanpa jejak. Dua mekanisme menjaga hal ini:

• Version history per workflow — n8n menyimpan riwayat versi, sehingga kalian bisa melihat siapa mengubah apa dan mengembalikan versi sebelumnya bila terjadi regresi.
• Source Control — pada lisensi yang mendukungnya, definisi workflow disinkronkan ke repository Git. Setiap perubahan menjadi commit yang terdokumentasi, dan workflow berpindah antar environment (staging ke produksi) melalui proses review seperti kode biasa.

git checkout -b fix/webhook-timeout
n8n workflow:update 42 --name "Laporan Harian v2"
git add workflows/laporan-harian.json
git commit -m "fix: naikkan timeout webhook laporan harian"
git push origin fix/webhook-timeout

Source control sinkron hanya mendorong definisi workflow — bukan credential. Workflow yang dipromosikan dari staging ke produksi mengharapkan credential bernama sama sudah ada di produksi dengan nilainya masing-masing. Ini dirancang agar rahasia tidak ikut berpindah antar environment. Prinsip change control sederhana: environment produksi tidak boleh diubah langsung oleh siapa pun, kecuali melalui alur yang terdokumentasi. Detail CI/CD untuk workflow akan dibahas di episode 18.

#Audit Trails

Jejak terakhir yang melengkapi tata kelola adalah audit log. Pada lisensi enterprise, n8n mencatat kejadian penting secara permanen: login user, perubahan workflow, pembuatan dan pembaruan credential, perubahan user atau role, serta aktivitas source control.

Audit trail menjawab pertanyaan yang diajukan saat investigasi insiden: siapa yang login terakhir, siapa yang mengubah workflow ini, kapan credential itu dirotasi. Karena catatan bersifat append-only, jejak ini bisa dijadikan bukti compliance. Untuk menyelaraskan dengan kebijakan organisasi, audit event juga bisa dialirkan ke SIEM atau dipadukan dengan observability yang dibangun di episode 13.

#Penutup

Episode 14 mengubah instance pribadi menjadi platform tim. Kalian memahami model role owner, admin, dan member berikut lapisan project dan RBAC, cara mengelola user dengan MFA dan SSO, berbagi workflow, credential, dan folder dengan kontrol terpisah, serta menjaga change control melalui version history dan source control yang dilengkapi audit trails.

Inti yang harus dibawa pulang:

• Hak akses berlapis: role instance menentukan batas global, project menentukan batas per-tim.
• Credential dibagikan lebih ketat daripada workflow — nilai kredensial tak pernah terlihat, hanya referensinya.
• Berbagi per resource, bukan per instance, memakai project dan folder sebagai struktur.
• Change control memakai version history dan source control Git, dengan credential yang tidak ikut tersinkron.
• Audit trails menjawab pertanyaan "siapa, kapan, dan apa" setiap kejadian penting.

Di episode 15 berikutnya kita mengeluarkan n8n dari laptop menuju produksi: Self-hosting & Deployment Patterns — deploy dengan Docker Compose, Kubernetes, dan cloud VM, menentukan storage backend dan database, sampai high availability dan scaling worker nodes. Sampai jumpa!