Belajar Vault - Vault Namespaces & Multi-Tenancy (Enterprise vs Open Source)

#Pendahuluan

Setelah di episode 22 sebelumnya kita mengamankan Vault dengan audit logging, hardening, dan otomatisasi backup — pada episode kali ini kita menggeser sudut pandang dari bagaimana mengamankan satu Vault menjadi bagaimana mengamankan satu Vault untuk banyak pemakai sekaligus. Topiknya: Vault Namespaces & Multi-Tenancy, dan bagaimana posisi Vault Open Source dibanding Enterprise.

Mari mulai dari pertanyaan yang sangat nyata di dunia kerja: organisasi kalian memutuskan untuk memusatkan semua secret management ke satu Vault cluster (keputusan yang bagus — ingat episode 1 tentang secret sprawl). Tim backend butuh credential database, tim data butuh kredensial warehouse, tim security mengelola PKI, dan masing-masing punya standar kebijakan sendiri. Sekarang bayangkan jika semuanya hidup di satu ruang bersama: satu daftar policy, satu set auth methods, satu cakupan path. Kesalahan satu tim — misalnya menulis policy yang terlalu permisif atau menghapus path milik tim lain — berdampak ke semua tim. Blast radius-nya satu organisasi.

Di sinilah konsep tenant atau namespace masuk. Di dunia nyata, kamu tidak akan membiarkan seluruh departemen berbagi satu ruang server tanpa partisi. Namespaces adalah partisi itu: isolasi total data, policy, dan auth method antar tim dalam satu cluster fisik. Episode ini akan menjelaskan mekanismenya, contoh penggunaannya, dan — yang sering disalahpahami — fitur mana yang tersedia di Vault Open Source dan mana yang eksklusif Enterprise.

#Pembahasan Utama

#Mengapa Multi-Tenancy Menjadi Kebutuhan, Bukan Pilihan

Ketika Vault mulai dipakai organisasi, ia biasanya dimulai oleh satu tim (misal platform). Begitu terbukti berguna, tim lain berbondong-bondong meminta akses. Tanpa pemisahan yang jelas, muncul masalah:

• Blast radius tidak terbatas — policy yang salah di satu tim bisa mengekspos secret tim lain.
• Audit tidak terpetakan — sulit menjawab "siapa di tim mana mengakses apa".
• Auth method bentrok — dua tim ingin memakai userpass dengan akun yang sama, atau OIDC dengan scope berbeda.
• Governance tidak jelas — siapa yang boleh mengaktifkan secrets engine, siapa yang boleh membuat namespace?

Multi-tenancy memecahkan semua ini dengan memberikan batas eksplisit: setiap tenant adalah dunia terpisah dengan policy, auth method, secrets engine, dan kebijakannya sendiri.

#Namespaces: Isolasi Total dalam Satu Cluster

Namespace adalah sebuah hierarki di dalam Vault yang mengisolasi data, policy, auth method, dan mount point. Ini bukan sekadar "folder yang rapi" — ini isolasi tingkat keamanan: policy yang ditulis di satu namespace tidak berlaku di namespace lain, dan data di satu namespace tidak bisa diakses oleh namespace lain kecuali dihubungkan secara eksplisit (fitur advanced/Enterprise).

Konsep ini paling mudah dipahami dengan analogi apartemen dalam satu gedung. Satu gedung (satu Vault cluster), tapi setiap unit apartemen (namespace) punya kunci sendiri, dekorasi sendiri, dan penghuni sendiri. Kamu tidak bisa masuk unit orang lain hanya karena kamu sudah masuk gedung.

Membuat namespace sangat mudah:

vault namespace create dev
vault namespace create prod

Key                Value
---                -----
id                 f4a9...
path               dev/

Setelah dibuat, gunakan flag -namespace atau environment variable VAULT_NAMESPACE untuk beroperasi di dalam namespace tersebut:

vault kv put -namespace=dev secret/data/app DB_HOST=10.0.1.5
vault kv get -namespace=dev secret/data/app

export VAULT_NAMESPACE=dev
vault kv put secret/data/app DB_HOST=10.0.1.5
vault kv get secret/data/app

Perhatikan pola path-nya: secara internal, path di namespace dev menjadi ber-prefix dev/. Jadi secret/data/app di namespace dev adalah dev/secret/data/app dalam terminologi root. Inilah yang membuat data antar namespace tidak bentrok — dan sekaligus menjadi sumber salah konfigurasi (akan kita bahas di bagian pitfalls).

#Namespace, Policy, dan Auth Method: Contoh Lengkap

Sekarang mari buat skenario lengkap: tim backend memakai namespace backend, dengan auth method userpass, dan policy yang hanya mengizinkan akses ke KV miliknya.

Pertama, aktifkan auth dan tulis policy di dalam namespace:

export VAULT_NAMESPACE=backend
 
# Aktifkan userpass khusus untuk namespace backend
vault auth enable userpass
 
# Buat user
vault write auth/userpass/users/back-dev \
  password="s3cret-banget" \
  policies=backend-app
 
# Daftar policy di namespace ini
vault policy list

backend-app
default

Policy backend-app ditulis di dalam namespace backend, sehingga scope-nya hanya berlaku untuk path di namespace tersebut:

path "secret/data/backend/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
 
path "secret/metadata/backend/*" {
  capabilities = ["list"]
}
 
path "database/creds/backend-role" {
  capabilities = ["read"]
}

Sekarang, user back-dev yang login di namespace backend tidak bisa mengakses path di namespace lain, karena policy-nya tidak menyentuh path di luar secret/data/backend/*. Coba akses silang akan ditolak:

vault login -method=userpass username=back-dev password=s3cret-banget

# Dalam namespace backend — bekerja
vault kv get secret/data/backend/api-key
 
# Coba akses namespace lain (secara eksplisit) — ditolak
VAULT_NAMESPACE=backend vault kv list secret/data/finance/
 
# Coba path di luar cakupan policy — ditolak
vault read database/creds/finance-role

Error making API request.
 
URL: GET https://vault.internal:8200/v1/secret/data/finance/api-key
Code: 403. Errors:
 
* 1 error occurred:
	* permission denied

#Namespace Bersarang (Hierarchical Namespaces)

Namespace tidak harus datar — mereka bisa bersarang (nested). Ini penting ketika organisasi punya hierarki: misalnya namespace engineering/ sebagai "gedung", lalu engineering/backend, engineering/data, dan engineering/security sebagai unit di dalamnya.

vault namespace create -namespace=engineering backend
vault namespace create -namespace=engineering data
vault namespace create -namespace=engineering/backend production

Perhatikan penggunaan -namespace pada command di atas: untuk membuat namespace di dalam namespace, kalian "masuk" dulu ke namespace induknya. Akibatnya, path lengkap menjadi engineering/backend/production/secret/data/app. Hierarki ini memberi fleksibilitas governance — misalnya, policy di level engineering/ bisa menetapkan aturan umum, sementara unit di dalamnya mengatur detailnya sendiri. Namun satu hal yang konsisten: semakin dalam hierarki, semakin panjang prefix path, dan semakin besar peluang salah ketik saat menulis policy. Simpan peta namespace kalian dalam dokumentasi, bukan di kepala.

#Vault Open Source vs Enterprise: Fitur yang Harus Dipahami

Bagian penting yang sering membingungkan orang: apakah Namespaces ada di Vault Open Source? Jawaban singkatnya — tidak. Namespaces adalah fitur Enterprise-exclusive. Vault Open Source berjalan dalam satu "namespace root" saja; semua pengguna berbagi satu ruang policy/auth mount.

Berikut perbandingan fitur utama:

Dua fitur Enterprise yang paling sering mendorong upgrade selain Namespaces:

• Disaster Recovery Replication — mereplikasi seluruh data ke cluster terpisah di region berbeda; jika cluster utama hilang, cluster DR di-promote menjadi aktif. Ini adalah jawaban "enterprise" untuk kekhawatiran DR di episode 20.
• Sentinel — policy yang bisa mengekspresikan kondisi kontekstual, misalnya "hanya izinkan membaca secret ini jika request datang dari IP internal DAN waktu dalam jam kerja". OSS hanya bisa policy statis berbasis path+capabilities.

#Catatan Lisensi: Vault OSS itu Gratis, Tapi…

Satu hal yang wajib kalian pahami sebelum merekomendasikan Vault ke organisasi mana pun: lisensinya. Sejak Vault versi 1.15 (rilis 2023), versi "community" Vault tidak lagi berlisensi OSI-approved open source seperti dulu. HashiCorp mengubahnya ke Business Source License (BSL 1.1):

• Vault BSL gratis untuk penggunaan internal perusahaan — menjalankan Vault untuk kebutuhan sendiri tidak dikenakan biaya.
• Kode boleh disalin, dimodifikasi, dan didistribusikan untuk penggunaan non-kompetitif.
• Larangan utamanya: menyediakan Vault sebagai layanan komersial yang bersaing langsung dengan produk HashiCorp (misal mengelola Vault-as-a-service untuk banyak pelanggan).
• Setelah Change Date (±4 tahun per rilis), versi tersebut otomatis beralih ke MPL 2.0 — artinya lisensi ini dirancang untuk "akhirnya menjadi open source".

Implikasi praktisnya:

• Kalian boleh memakai Vault komunitas di production internal tanpa bayar, termasuk untuk klien enterprise — selama bukan menjual ulang Vault sebagai layanan kompetitif.
• Bagi tim yang ingin kepastian lisensi open source penuh, ada OpenBao — fork komunitas dari Vault (sebelumnya bernama OpenBao, turunan Vault 1.14) yang dijalankan di bawah MPL 2.0. Fitur-fiturnya sebagian besar setara dengan Vault OSS, namun perkembangan fitur bisa berbeda dari Vault resmi.
• Vault Enterprise tetap berlisensi komersial dan berbayar per fitur (Namespaces, Replication, Sentinel, dll.), biasanya via langganan.

#Kesalahan Umum (Common Pitfalls)

#Penutup

Pada episode 23 ini kita telah membahas konsep multi-tenancy lewat Namespaces — isolasi total data, policy, auth method, dan secrets engine antar tim dalam satu cluster — lengkap dengan contoh praktis vault namespace create, penggunaan VAULT_NAMESPACE, serta policy dan auth method yang bersifat namespace-aware. Kita juga membandingkan fitur Vault Open Source vs Enterprise: Namespaces, DR/Performance Replication, Sentinel, dan Performance Standby adalah fitur Enterprise, sementara inti Vault (secrets engines, auth, audit, HA, auto-unseal) tersedia di Open Source. Terakhir, kita membedah lisensi BSL Vault beserta implikasi praktisnya dan alternatif OpenBao.

Kalian kini memiliki Vault yang aman, tersedia, terdokumentasi dengan baik, dan — dengan keputusan arsitektur yang tepat — mampu melayani banyak tim. Tapi ada satu pertanyaan yang tersisa: bagaimana kalian tahu bahwa semuanya berjalan sehat? Bagaimana memantau apakah ada node yang sealed tanpa kalian sadari, mengukur latensi request, atau mendiagnosis kenapa aplikasi tiba-tiba dapat permission denied? Itulah materi penutup teknis kita: Observability, Monitoring & Troubleshooting di episode 24. Pastikan tetap semangat! 📊