Belajar Secret Management - Arsitektur Utama & Operasi Inisialisasi (Raft Storage & Unsealing)

#Pendahuluan

Di episode 1 kalian memahami mengapa OpenBao dipilih: open source, kompatibel dengan Vault, dan kaya fitur. Episode 2 ini masuk ke bagian paling fundamental sekaligus paling sering disalahpahami: apa yang terjadi di dalam OpenBao saat pertama kali dijalankan.

Dua konsep wajib paham di sini adalah storage backend (di mana data diletakkan) dan seal/unseal (bagaimana data dibuka kuncinya). Setelah episode ini, kalian akan tahu mengapa server OpenBao yang baru diinisialisasi selalu dimulai dalam kondisi sealed, dan mengapa unseal key harus dipegang oleh orang yang tepat.

#Arsitektur Utama OpenBao

#Storage Backend: Raft Integrated Storage vs Consul

Storage backend adalah tempat OpenBao menyimpan data persistennya — tetapi perlu ditekankan sejak awal: storage ini tidak pernah menyimpan data plaintext. Semua yang masuk melewati lapisan enkripsi barrier sebelum ditulis. Pilihan utama storage backend di produksi:

Raft adalah pilihan paling masuk akal untuk sebagian besar tim karena OpenBao menangani konsistensi dan replikasi sendiri. Konsul tetap relevan di organisasi yang sudah memiliki infrastruktur Consul yang dioperasikan dengan baik. Pilihan ini akan kalian bedah lebih dalam di episode 15 tentang high availability.

#OpenBao Core & Barrier Engine

Di tengah arsitektur OpenBao terdapat core — mesin utama yang memproses setiap request API. Salah satu komponen terpentingnya adalah barrier, lapisan enkripsi yang melindungi semua data yang masuk dan keluar dari storage.

Alur singkatnya begini: request datang ke core, dimuat dengan token dan policy, lalu saat data ditulis, barrier mengenkripsi data dengan master key sebelum disimpan ke storage backend. Saat dibaca, barrier mendekripsinya kembali. Karena enkripsi terjadi di barrier, bukan di storage, maka seburuk apapun backend storage-nya, data tidak pernah bocor dalam bentuk aslinya.

#Proses Initialization

Saat server pertama kali dijalankan, OpenBao berada dalam kondisi uninitialized — belum punya master key sama sekali. Di sinilah bao operator init berperan.

#Shamir's Secret Sharing: Master Key Menjadi Unseal Keys

Inisialisasi menghasilkan master key — kunci yang mengunci barrier. Masalahnya, menyimpan master key utuh di satu tempat justru menciptakan single point of failure. Jika hilang, seluruh data tidak bisa dibuka selamanya. Solusinya adalah Shamir's Secret Sharing.

Prinsip Shamir sederhana namun elegan: master key dipecah menjadi N potongan yang disebut unseal keys, dan untuk menyatukannya kembali dibutuhkan minimal K potongan. Skema ini ditulis sebagai N-of-K:

Semakin tinggi K, semakin aman — tapi semakin sulit saat benar-benar butuh unseal. Praktik umum di produksi: 3-of-5, dibagikan ke lima orang berbeda. Tidak ada satu orang pun yang bisa membuka OpenBao sendirian, tapi mayoritas selalu bisa membukanya.

Jalankan inisialisasi dengan skema yang diinginkan:

bao operator init -key-shares=5 -key-threshold=3

Output akan menampilkan lima unseal keys dan satu root token. Simpan semuanya dengan aman — misalnya dibagi antar anggota tim di lokasi terpisah — karena output ini tidak akan pernah ditampilkan lagi.

#Unsealing Manual

Setelah inisialisasi, setiap kali server dimulai ulang, OpenBao masuk dalam kondisi sealed — barrier terkunci, data tidak bisa diakses. Untuk membukanya, kalian harus memasukkan unseal keys hingga mencapai threshold:

bao operator unseal
bao operator unseal
bao operator unseal
bao status

Setiap bao operator unseal meminta satu unseal key. Setelah K unseal key yang benar dimasukkan, status berubah menjadi Unsealed: true dan server siap melayani request. Sampai threshold tercapai, data tetap aman — tidak ada satu key pun yang cukup sendirian.

Perhatikan bahwa server yang sealed bukan berarti mati — endpoint status tetap merespons, karena itulah cara kalian tahu kondisi server. Yang terkunci adalah barrier di dalamnya.

#Auto-Unseal Mechanism

Unseal manual setiap kali server reboot adalah beban operasional nyata — dan berbahaya, karena memaksa unseal keys dibawa ke mesin server. Solusinya adalah auto-unseal: master key dibungkus dengan kunci dari cloud KMS, sehingga saat server boot, OpenBao bisa membuka seal sendiri tanpa campur tangan manusia.

storage "raft" {
  path = "/data/openbao"
}
 
seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "alias/openbao-unseal"
}
 
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = true
}
 
disable_mlock = false

Penyedia yang didukung antara lain AWS KMS, GCP Cloud KMS, dan Azure Key Vault. Keuntungannya bukan hanya kenyamanan: karena unseal keys tidak lagi disimpan di server, risiko pencurian kunci juga menurun drastis. Konsep auto-unseal ini akan diperdalam dengan konfigurasi lengkap di episode 16.

#Manajemen Root Token

Saat inisialisasi, OpenBao juga mencetak root token — token dengan hak tanpa batas (privilege superuser). Di dev mode, root token memang dipakai untuk praktik. Di produksi, root token adalah ancaman yang harus ditangani dengan serius.

#Risiko Root Token

• Hak absolut — pemegangnya bisa melakukan apa saja, termasuk menghapus seluruh secrets dan menonaktifkan engine.
• Tidak terbatas — tanpa TTL, jadi tidak pernah kedaluwarsa secara otomatis.
• Target utama penyerang — satu token bocor berarti kendali penuh atas sistem.

#Praktik Terbaik Revocation di Produksi

• Revoke segera setelah setup selesai — gunakan bao token revoke <root-token-id> begitu semua operasi awal selesai. Operasi normal tidak pernah membutuhkan root token.
• Gunakan policy dan token khusus untuk setiap tugas — admin, operator, dan pengembang mendapat hak sesuai perannya.
• Simpan root token terenkripsi jika memang harus diarsipkan — misalnya di tempat penyimpanan yang dibuka dengan proses multi-approval.
• Uji pemulihan berkala — pastikan tim masih bisa unseal tanpa root token sebelum benar-benar menghapusnya.

#Penutup

Pada episode 2 ini, kalian memahami arsitektur utama OpenBao: storage backend dengan Raft dan Consul, barrier engine yang mengenkripsi semua data, inisialisasi dengan Shamir secret sharing N-of-K, unsealing manual dengan bao operator unseal, auto-unseal berbasis cloud KMS, serta manajemen root token yang ketat.

Inti yang harus dibawa pulang:

• Storage backend tidak pernah menyimpan plaintext — semua data dilindungi barrier sebelum masuk storage.
• Shamir N-of-K adalah jaminan keamanan kolektif — 3-of-5 adalah titik keseimbangan yang umum dipakai.
• Unseal keys hanya dicetak sekali — distribusikan dan simpan seperti nyawa kalian.
• Root token dicabut setelah setup — operasi produksi berjalan dengan token ber-policy, bukan superuser.

Di episode 3 berikutnya kita mulai memakai OpenBao untuk hal yang paling dasar: KV Secrets Engine — cara menyimpan dan membaca secrets dengan bao kv put, bao kv get, dan bao kv list, plus perbandingan lengkap KV v1 versus KV v2 beserta versioning, metadata, soft delete, dan permanent destroy. Siapkan server dev mode kalian, karena dari episode ini mulai ada secret yang benar-benar tersimpan!