Belajar Secret Management - Migrasi dari HashiCorp Vault ke OpenBao di Produksi

#Pendahuluan

Setelah episode 17 memperlengkapi kalian dengan audit logging, hardening, dan backup raft snapshot, episode 18 ini menuntut kalian menggunakan semua itu dalam ujian nyata: migrasi dari HashiCorp Vault ke OpenBao di produksi. Ini bukan sekadar mengganti binary — ini memindahkan seluruh jejak data, kebijakan, mount, dan cara kerja tim ke platform yang berbeda tanpa menghentikan layanan yang bergantung padanya.

Kabar baiknya, migrasi ini justru termasuk yang paling halus di dunia secret management. OpenBao lahir sebagai fork dari Vault dan dirancang backward compatible dengan Vault versi 1.15.x ke bawah, sehingga format storage, struktur API, dan sintaks CLI sebagian besar tetap sama. Yang menjadi pekerjaan kalian adalah memvalidasi klaim itu di lingkungan sendiri, bukan menelan mentah-mentahnya.

#Dua Strategi Migrasi

Secara garis besar ada dua jalur untuk sampai ke OpenBao. Pilihan di antara keduanya bergantung pada seberapa banyak kendali yang kalian miliki atas infrastruktur lama.

Kedua jalur itu sah-sah saja. Yang penting, apapun pilihannya, kalian harus mulai dari langkah yang sama: backup menyeluruh dan validasi konfigurasi.

#Persiapan: Backup dan Validasi Konfigurasi

Sebelum menyentuh apa pun, pastikan ada dua hal yang bisa mengembalikan keadaan semula: snapshot data dan salinan konfigurasi aktif.

bao operator raft snapshot save /backups/pre-migration.snap
cp /etc/vault/config.hcl /backups/vault-config.hcl

Setelah backup aman, validasi konfigurasi lama terhadap sintaks OpenBao. Sebagian besar blok config Vault bisa dipakai langsung, tetapi tetap perlu diperiksa karena beberapa parameter versi lama tidak dikenal atau sudah berubah nama:

Config yang divalidasi

storage "raft" {
  path = "/vault/data"
  node_id = "node-a"
}
 
listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = "false"
  tls_cert_file = "/etc/openbao/tls/server.crt"
  tls_key_file = "/etc/openbao/tls/server.key"
}

Uji dengan mode dry-run: jalankan OpenBao dengan flag -config dan lihat apakah proses berhasil memuat konfigurasi tanpa error. Ini jauh lebih murah daripada menemukan kesalahan konfigurasi di tengah jam produksi. Jangan lupa pula memeriksa disable_mlock, ui, dan blok seal yang kalian kenali dari episode 16.

#Jalur 1: In-Place Upgrade

In-place upgrade adalah jalur paling sederhana. Prinsipnya: hentikan Vault, ganti binary-nya dengan binary OpenBao, lalu hidupkan kembali dengan data yang sama.

systemctl stop vault
cp /usr/local/bin/vault /usr/local/bin/vault.bak
install -m 0755 /tmp/openbao /usr/local/bin/bao
ln -sf /usr/local/bin/bao /usr/local/bin/vault
systemctl start bao
bao status

Karena format storage Vault 1.15.x masih dipahami OpenBao, data raft yang sudah ada langsung bisa dibaca. Setelah start, verifikasi bahwa node tidak sealed dan, bila perlu, lakukan unseal seperti biasa. Seluruh data, mount, dan policy yang tersimpan di storage ikut terbawa — tidak ada ekspor-impor manual.

#Jalur 2: Migrasi Storage

Ketika kalian tidak bisa mengganti binary di server lama — misalnya server dikelola vendor atau sedang tidak bisa di-restart — gunakan jalur migrasi storage: pindahkan snapshot raft ke cluster OpenBao yang baru berdiri.

bao operator raft snapshot restore /backups/pre-migration.snap

Sebelum restore, pastikan node target masih kosong dan belum diinisialisasi. bao operator raft snapshot restore akan menimpa data yang ada dengan isi snapshot, jadi urutan pemindahan file dan waktu eksekusi harus direncanakan dengan hati-hati. Jalur ini juga memberi kesempatan untuk merapikan konfigurasi: alamat listener, sertifikat baru, dan auto-unseal cloud bisa disiapkan sejak awal di node target.

#Validasi Kompatibilitas API dan CLI

Setelah data berpindah, pekerjaan sebenarnya baru dimulai: meyakinkan semua konsumen bahwa API lama masih berbicara bahasa yang sama. OpenBao mempertahankan endpoint API /v1/... yang identik dengan Vault, sehingga klien lama — aplikasi, SDK, agent, dan tooling — tetap berfungsi tanpa perubahan kode.

curl --silent https://openbao.example.com/v1/sys/health
alias vault=bao
vault read secret/data/myapp

Buat daftar endpoint yang dipakai tim kalian dari episode-episode sebelumnya — auth/approle/login, database/creds/web-role, transit/encrypt/my-key, pki_int/issue/my-role — lalu uji satu per satu di staging. Sementara itu, alias vault=bao dipasang di shell tim agar semua skrip dan dokumentasi lama tetap jalan tanpa diedit. Ini langkah kecil dengan dampak besar: seluruh kebiasaan vault di tim tidak perlu diubah seketika.

#Validasi Plugin dan Rolling Migration

Tidak semua hal bisa dibawa otomatis. Plugin eksternal yang ditulis untuk Vault mungkin perlu dibangun ulang untuk OpenBao, dan auth method atau secrets engine komunitas harus dicek ketersediaannya. Lakukan validasi plugin di staging terlebih dahulu:

bao plugin list
bao secrets list
bao auth list

Untuk cluster besar, gunakan rolling migration dengan zero downtime: tambahkan node OpenBao baru ke cluster lewat bao operator raft join (ingat episode 15), biarkan data tersinkronisasi, lalu keluarkan node Vault lama satu per satu. Dengan cara ini, tidak ada momen di mana seluruh sistem tidak punya pemimpin aktif. Setelah semua node menjadi OpenBao, audit log dari episode 17 akan mencatat seluruh proses ini — jejak yang bagus untuk compliance.

#Penutup

Pada episode 18 kalian memetakan dua strategi migrasi dari HashiCorp Vault ke OpenBao — in-place upgrade untuk mengganti binary di tempat, dan storage migration untuk memindahkan data ke cluster baru — plus disiplin yang menyertainya: backup menyeluruh, validasi konfigurasi, uji endpoint /v1/..., alias vault=bao agar tim tidak tersentak, validasi plugin, serta rolling migration tanpa downtime.

Inti yang harus dibawa pulang:

• Backward compatibility dengan Vault 1.15.x adalah aset utama — tapi tetap harus divalidasi di lingkungan sendiri.
• alias vault=bao membuat transisi CLI nyaris tak terasa bagi tim.
• Uji endpoint /v1/... satu per satu di staging sebelum go-live.
• Siapkan window rollback — migrasi yang bisa dibatalkan adalah migrasi yang aman.

Di episode 19 berikutnya, kalian akan berhadapan dengan dunia yang lebih gelap: troubleshooting dan operational maintenance — ketika cluster bermasalah, node sealed, token kedaluwarsa, atau quorum raft hilang. Siapkan mental kalian.