Belajar Secret Management - Automated Auto-Unseal Strategy di Cloud
Mengotomatiskan unseal OpenBao pasca maintenance dengan cloud KMS: konfigurasi seal awskms di AWS, gcpckms di Google Cloud, serta azurekeyvault di Microsoft Azure agar server langsung siap melayani.
#Pendahuluan
Di episode 15 kalian membangun cluster HA dengan Raft dan kuorum node. Episode 16 menyelesaikan satu masalah operasional yang tersisa: setiap kali server restart — entah karena maintenance atau reboot — OpenBao kembali terkunci dan harus di-unseal manual. Dengan auto-unseal berbasis cloud KMS, server membuka kuncinya sendiri saat boot.
#Kenapa Unseal Manual Menjadi Masalah
OpenBao menyimpan master key-nya terenkripsi; untuk membacanya, kalian harus memasukkan sejumlah key share sampai threshold terpenuhi. Pada mode Shamir, itu berarti manusia harus hadir setiap kali server hidup. Bayangkan lima node cluster yang reboot bersamaan — semuanya menunggu manusia.
Auto-unseal memindahkan tanggung jawab ini ke cloud KMS: root key dienkripsi dengan kunci KMS, dan saat boot OpenBao meminta KMS membuka enkripsinya. Server langsung aktif tanpa campur tangan manusia, yang sangat berarti untuk autoscaling dan pemulihan bencana.
#Bagaimana Auto-Unseal Bekerja
Mekanismenya mirip: alih-alih membagi master key menjadi shares, OpenBao menyerahkan enkripsi root key kepada KMS. Saat startup, OpenBao menghubungi KMS dengan kredensial yang dikonfigurasi, mendekripsi root key, dan melanjutkan ke status unsealed. Unseal key manual tidak lagi diperlukan setiap restart.
#Konfigurasi Auto-Unseal
Blok seal di konfigurasi menentukan penyedia KMS. Berikut ketiganya.
#AWS KMS
seal "awskms" {
region = "ap-southeast-1"
kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/abcd1234"
}
storage "raft" {
path = "/opt/openbao/data"
node_id = "node1"
}Kredensial AWS diambil dari AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY, dari instance profile, atau dari konfigurasi SDK. Pastikan role tersebut memiliki izin kms:Decrypt dan kms:Encrypt pada kunci yang ditunjuk kms_key_id.
#GCP Cloud KMS
seal "gcpckms" {
project = "my-project"
region = "global"
key_ring = "openbao-keys"
crypto_key = "openbao-unseal"
}Otentikasi GCP memakai Application Default Credentials. OpenBao mencari kunci pada key_ring dan crypto_key yang ditunjuk, di region yang ditentukan. Izin cloudkms.cryptoKeyVersions.useToDecrypt diperlukan.
#Azure Key Vault
seal "azurekeyvault" {
tenant_id = "12345678-1234-1234-1234-123456789012"
client_id = "12345678-1234-1234-1234-123456789013"
client_secret = "client-secret"
vault_name = "openbao-kv"
key_name = "openbao-unseal"
}Service principal dengan permission unwrap pada key di Key Vault menjadi kredensial yang dipakai. Setiap penyedia punya parameter dan cara otentikasi sendiri, tetapi hasil akhirnya sama: server membuka dirinya sendiri.
#Perbandingan Penyedia KMS
| Aspek | AWS KMS | GCP Cloud KMS | Azure Key Vault |
|---|---|---|---|
| Blok seal | awskms | gcpckms | azurekeyvault |
| Otentikasi | Access key atau instance profile | Application Default Credentials | Service principal |
| Parameter utama | region, kms_key_id | project, key_ring, crypto_key | tenant_id, vault_name, key_name |
| Izin kunci | kms:Decrypt dan Encrypt | useToDecrypt | unwrap key |
Pilih penyedia sesuai tempat kalian sudah berjalan di cloud. Semua mendukung tujuan yang sama: menghapus ritual unseal manual.
Important
Kunci KMS yang dipakai untuk auto-unseal adalah penjaga terakhir dari semua rahasia. Lindungi akses ke kunci itu seketat mungkin — siapa pun yang bisa membuka kunci KMS bisa membuka OpenBao. Contoh: batasi IAM role hanya untuk kms:Decrypt pada kunci tertentu.
#Bermigrasi dari Seal Shamir ke KMS
Jika kalian sudah lama memakai seal Shamir, tidak perlu membangun dari nol. OpenBao mendukung migrasi seal: ubah blok seal pada konfigurasi, restart server, lalu unseal satu kali dengan key shares yang lama.
bao operator unseal
bao operator unseal
bao operator unsealSetelah threshold Shamir terpenuhi pada proses migrasi, root key dienkripsi ulang menggunakan kunci KMS yang baru. Mulai saat itu, bao operator unseal tidak lagi dipanggil manual — server membuka dirinya sendiri lewat KMS setiap boot.
Tip
Simpan key shares lama sampai migrasi benar-benar terbukti berhasil. Setelah server restart dan kembali unsealed otomatis, barulah key shares lama dapat dimusnahkan dengan aman.
#Batasan dan Pertimbangan Keamanan
Auto-unseal bukan sihir. Jika KMS tidak terjangkau saat boot, OpenBao tetap terkunci sampai koneksi pulih. Untuk kesiapan penuh:
- Pastikan kredensial KMS disimpan di tempat yang aman: secrets manager, instance profile, atau service account.
- Kombinasikan dengan HA cluster agar failover tidak menunggu manusia.
- Uji skenario pemulihan: matikan node, reboot, dan pastikan ia kembali unsealed tanpa intervensi.
#Penutup
Pada episode 16 ini, kalian memahami alasan unseal manual menjadi beban operasional, cara kerja auto-unseal berbasis KMS, serta konfigurasi seal "awskms", seal "gcpckms", dan seal "azurekeyvault" agar OpenBao langsung siap melayani setelah server boot.
Inti yang harus dibawa pulang:
- Auto-unseal memindahkan enkripsi root key dari shamir shares ke cloud KMS.
- Server membuka dirinya sendiri saat boot tanpa campur tangan manusia.
- Pilih penyedia sesuai infrastruktur: AWS, GCP, atau Azure.
- Lindungi kunci KMS seketat mungkin; ia adalah fondasi keamanan seluruh klaster.
Di episode 17 berikutnya, kita menutup lapisan terakhir sebelum produksi: audit logging, security hardening, dan compliance untuk menjaga OpenBao tetap transparan dan terdokumentasi.