Belajar Secret Management - Troubleshooting dan Operational Maintenance

#Pendahuluan

Setelah episode 18 kalian berhasil memindahkan seluruh sistem ke OpenBao di produksi, pertanyaan berikutnya adalah pertanyaan paling jujur dalam operasional: apa yang terjadi saat segalanya berjalan salah? Episode 19 ini membekali kalian dengan perintah diagnostik dan pola pikir pemecahan masalah — dari node yang tiba-tiba sealed, permintaan yang ditolak karena policy, token yang kedaluwarsa di tengah job, sampai skenario terburuk berupa hilangnya quorum raft dan split brain.

Troubleshooting OpenBao jarang butuh keajaiban. Sebagian besar insiden bisa diidentifikasi dari urutan yang teratur: baca status, lihat peers, ambil data debug, lalu cocokkan gejalanya dengan daftar masalah umum. Di episode ini kalian akan menguasai urutan itu.

#Perintah Diagnostik Operasional

Tiga perintah berikut adalah fondasi dari semua pekerjaan troubleshooting. Hafalkan dan biasakan memakainya sebelum memutuskan sesuatu:

bao status
bao operator raft list-peers
bao debug -output=/tmp/bao-debug.tar.gz

• bao status — memberi gambaran cepat: apakah node aktif atau standby, tersegel atau terbuka, dan berapa lama waktu aktifnya.
• bao operator raft list-peers — menampilkan anggota cluster raft, peran mereka sebagai leader atau follower, dan status koneksi antar node.
• bao debug — mengemas informasi lengkap: config, status, log, trace, dan metrik ke dalam satu arsip yang bisa dikirim ke rekan tim atau dianalisis setelah insiden.

bao status adalah perintah pertama yang dijalankan hampir di setiap insiden. Ia membedakan dua keadaan paling fundamental dari OpenBao.

#Sealed vs Unsealed: Keadaan Paling Dasar

OpenBao tidak bisa diakses selama sealed — keadaan di mana data terenkripsi disimpan tetapi kunci untuk membukanya tidak ada di memori. Perbedaan antara keduanya sangat menentukan arah troubleshooting:

Jika bao status menampilkan Sealed: true, kemungkinan besar penyebabnya adalah server baru saja di-restart dan proses unseal belum dijalankan. Solusinya adalah memasukkan kunci unseal — atau membiarkan auto-unseal cloud dari episode 16 bekerja otomatis. Yang perlu dicurigai adalah node yang sealed tanpa restart: bisa jadi ada masalah dengan KMS, kunci berubah, atau konfigurasi seal rusak.

#Masalah Umum, Penyebab, dan Solusi

Berikut peta masalah yang paling sering ditemui di lapangan. Cocokkan gejala dengan baris yang relevan, lalu terapkan solusinya:

#Permission Denied dan Policy Mismatch

Pesan permission denied adalah keluhan paling umum dari pengguna aplikasi. Ini jarang berarti sistem rusak — biasanya artinya token yang dipakai tidak punya policy yang mengizinkan akses ke path tertentu. Sebelum menebak-nebak, periksa kapabilitas token yang sedang aktif:

bao token capabilities secret/data/myapp
bao token lookup

bao token lookup menunjukkan policy yang menempel pada token, sedangkan bao token capabilities menunjukkan aksi yang diizinkan pada path tertentu. Jika token memakai policy dari episode 7 dan path tidak cocok dengan pola yang ditulis — misalnya kalian menulis secret/data/myapp/* padahal aplikasi membaca secret/data/myapp persis — maka deny akan terjadi. Koreksi policy dan ingat: aturan deny bersifat akhir, apapun policy lain yang mengizinkan.

#Token Expired dan Job yang Terputus

Token memiliki TTL, dan ketika kedaluwarsa semua operasi yang bergantung padanya ikut mati. Gejalanya khas: aplikasi berjalan normal selama beberapa jam, lalu mulai menolak dengan error autentikasi. Pemicunya biasanya salah satu dari dua hal: aplikasi memakai token statis yang tidak pernah di-renew, atau agent tidak dijalankan dengan auto-auth.

bao token lookup -format=json
bao lease renew <lease_id>

Untuk beban produksi, pola yang benar sudah kalian pelajari di episode 11: biarkan OpenBao agent menangani login dan renewal otomatis, alih-alih token statis yang disimpan di file konfigurasi. Token statis yang TTL-nya pendek adalah sumber insiden paling mudah dicegah di seluruh operasional secret management.

#Loss of Raft Quorum dan Split Brain

Ini adalah skenario terberat. Raft membutuhkan mayoritas node hidup untuk membentuk quorum dan memilih leader — pada cluster 3 node, dibutuhkan minimal 2 node yang sehat. Jika dua node mati sekaligus, cluster kehilangan quorum dan semua operasi tulis berhenti.

bao operator raft list-peers
bao operator raft autopilot state

Split brain terjadi ketika koneksi jaringan antar node terputus tetapi masing-masing sisi masih menganggap dirinya bagian dari cluster yang sehat. Raft dirancang mencegah dua leader aktif: hanya sisi yang memegang quorum yang sah. Karena itu, perbaikan utamanya bukan menulis data, melainkan memulihkan jaringan dan membiarkan konsensus menegakkan kebenaran. Jangan mencoba mengutak-atik data raft secara manual — itu justru memperparah.

#Prosedur Pemulihan

Ketika semuanya sudah dipahami, berikut urutan pemulihan standar yang bisa diterapkan:

1. Restart node yang gagal — mulai dari yang paling sehat, biarkan ia bergabung kembali ke cluster.

systemctl restart bao
bao status
bao operator raft list-peers

2. Re-join node — jika node baru perlu dimasukkan ke cluster, gunakan bao operator raft join seperti di episode 15, dengan alamat leader yang benar.

3. Restore snapshot — bila mayoritas node rusak permanen, bangun satu node baru dan kembalikan data dari snapshot terakhir.

bao operator raft snapshot restore /backups/backup.snap

4. Perbaiki akar masalah — snapshot hanya memulihkan data, bukan penyebabnya. Selidiki mengapa node mati: kehabisan disk, memori, atau masalah jaringan. Kembalikan node tambahan, konfirmasi quorum kembali normal, dan pastikan snapshot otomatis dari episode 17 terus berjalan.

#Penutup

Pada episode 19 kalian menguasai urutan troubleshooting yang teratur: membaca bao status untuk keadaan sealed atau unsealed, memeriksa anggota cluster dengan bao operator raft list-peers, dan mengemas bukti dengan bao debug. Kalian juga memetakan masalah umum — node sealed, permission denied karena policy mismatch, token expired, serta hilangnya quorum dan split brain — dan mempraktikkan prosedur pemulihan dari restart node, re-join, sampai restore snapshot.

Inti yang harus dibawa pulang:

• Mulai dari bao status — ia langsung memisahkan masalah keamanan dari masalah infra.
• Policy mismatch adalah penyebab paling umum permission denied — periksa token capabilities, bukan mencurigai server.
• Token expired bisa dicegah dengan renewal terpusat atau auto-auth agent.
• Split brain diselesaikan dengan memulihkan jaringan — jangan pernah menulis data raft secara manual.

Di episode 20 — episode terakhir series ini — kalian akan menggabungkan semua kemampuan dari episode 0 sampai 19 ke dalam satu rancangan utuh: complete production-grade OpenBao architecture untuk secret management terpadu skala enterprise yang 100% open source.