Belajar Vault - Automated Auto-Unseal Strategy pada Cloud Environment

#Pendahuluan

Setelah di episode 20 sebelumnya kita membangun Vault HA Cluster dengan Raft Integrated Storage — 3 node yang saling mereplikasi data dan otomatis memilih leader baru saat node mati — pada episode kali ini kita akan menyelesaikan masalah yang sengaja kita biarkan menggantung: unseal manual. Kalian sudah merasakannya sendiri saat praktik: setiap node restart, seseorang harus hadir mengetik Unseal Keys satu per satu. Di lab, ini terasa seperti ritual yang menarik. Di production, ini adalah latihan menantang waktu yang bisa menjatuhkan bisnis.

Bayangkan skenario nyata: pukul 03.00 dini hari, sebuah security patch mengharuskan reboot semua server termasuk ketiga node Vault kalian. Setelah reboot selesai, seluruh cluster kembali sealed. Aplikasi yang mencoba menarik dynamic database credentials mulai gagal, lalu cascade ke seluruh sistem. Satu-satunya penyelamat adalah operator yang punya Unseal Keys — dan dia sedang tidur. Inilah yang membuat auto-unseal bukan sekadar kenyamanan, melainkan bagian dari availability engineering.

Episode ini akan membahas bagaimana mekanisme auto-unseal bekerja (envelope encryption), bagaimana mengonfigurasinya di tiga cloud provider utama (AWS KMS, GCP Cloud KMS, Azure Key Vault), bagaimana perbandingan keamanannya dengan unseal manual, serta perangkap yang harus kalian waspadai — karena konfigurasi KMS yang salah bisa membuat Vault terkunci selamanya.

#Pembahasan Utama

#Mengingat Kembali: Mengapa Vault Perlu Unseal?

Dari episode 3, kita tahu bahwa saat Vault diinisialisasi, kunci enkripsi data (yang melindungi seluruh secret) dipecah menjadi beberapa bagian menggunakan Shamir's Secret Sharing Algorithm. Kunci ini disebut root key. Vault menyimpan root key tersebut dalam bentuk terenkripsi — dan untuk men-dekripsinya, dibutuhkan minimal threshold (misal 3 dari 5) Unseal Keys. Selama belum di-unseal, Vault menolak semua operasi: tidak bisa membaca secret, tidak bisa membuat token, tidak bisa menerbitkan sertifikat. Intinya, sealed = sistem mati total.

Masalahnya: siapa yang memegang Unseal Keys? Jika disimpan oleh banyak orang (pemisahan tugas yang baik), maka saat emergency justru semakin sulit mengumpulkan mereka. Jika disimpan satu orang saja, keamanan berkurang drastis. Ada ketegangan abadi antara keamanan dan ketersediaan. Auto-unseal menawarkan jalan keluar yang elegan.

#Envelope Encryption: Konsep di Balik Auto-Unseal

Auto-unseal tidak menghilangkan konsep root key — ia memindahkan custodian-nya. Konsepnya dikenal sebagai envelope encryption:

1. Vault memiliki root key (barrier key) yang mengenkripsi seluruh data di storage.
2. Root key tersebut dibungkus (wrapped) oleh KMS key di cloud provider, menghasilkan ciphertext yang disimpan di storage Vault.
3. Saat Vault boot, ia memanggil Cloud KMS API untuk meminta dekripsi wrapped root key.
4. Begitu root key kembali dalam bentuk plaintext, Vault membuka barrier dan menjadi unsealed — secara otomatis, tanpa manusia.

Analogi dunia nyata: Unseal manual itu seperti menyimpan brankas yang hanya bisa dibuka oleh kombinasi yang dipecah menjadi beberapa bagian dan dipegang orang berbeda — aman, tapi merepotkan. Auto-unseal seperti brankas yang membuka sendiri setelah memverifikasi sidik jari pemiliknya kepada pihak ketiga terpercaya (KMS). Aman, cepat, dan otomatis.

Yang perlu digarisbawahi: kredensial KMS dan role IAM justru menjadi target utama penyerang — karena siapa pun yang bisa memanggil KMS untuk mendekripsi wrapped key, bisa membuka segel Vault. Karena itu, keamanan auto-unseal sangat bergantung pada kualitas kontrol akses ke KMS.

#Konfigurasi Auto-Unseal dengan AWS KMS

Langkah pertama adalah menyiapkan Customer Master Key (CMK) di AWS KMS dan memberikan akses ke instance Vault. Cara paling aman adalah memberi Vault akses lewat IAM Role yang di-attach ke EC2 instance (bukan access key statis di file konfigurasi).

Pertama, buat IAM policy yang hanya mengizinkan operasi enkripsi/dekripsi KMS pada satu key tertentu:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo"
      ],
      "Resource": "arn:aws:kms:ap-southeast-1:123456789012:key/1234abcd-5678-90ef-ghij-klmnopqrstuv"
    }
  ]
}

Prinsip least privilege: policy ini hanya memberi akses ke satu key KMS, bukan semua key di akun. Setelah role di-attach ke instance, konfigurasi Vault cukup menambahkan blok seal "awskms":

seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "1234abcd-5678-90ef-ghij-klmnopqrstuv"
  endpoint   = "https://kms.ap-southeast-1.amazonaws.com"
}
 
storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
}
 
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = true
}

#Konfigurasi Auto-Unseal dengan GCP Cloud KMS

Di Google Cloud, alurnya mirip: buat Crypto Key di Cloud KMS, berikan akses ke Service Account yang dijalankan oleh VM, lalu konfigurasi Vault menggunakan seal "gcpckms". Berikut langkah setup key-nya:

gcloud services enable cloudkms.googleapis.com
 
# Buat key ring dan crypto key
gcloud kms keyrings create vault-keyring --location global
gcloud kms keys create vault-unseal \
  --location global \
  --keyring vault-keyring \
  --purpose encryption
 
# Buat service account untuk instance Vault
gcloud iam service-accounts create vault-sa \
  --display-name "Vault Auto-Unseal"
 
# Beri izin enkripsi/dekripsi ke crypto key tersebut
gcloud kms keys add-iam-policy-binding vault-unseal \
  --location global \
  --keyring vault-keyring \
  --member "serviceAccount:vault-sa@PROJECT.iam.gserviceaccount.com" \
  --role "roles/cloudkms.cryptoKeyEncrypterDecrypter"

Perhatikan role yang digunakan: cloudkms.cryptoKeyEncrypterDecrypter — minimal, hanya mencakup enkripsi dan dekripsi. Jangan pernah memberikan role yang lebih luas seperti cloudkms.admin ke service account aplikasi.

Lalu konfigurasi Vault:

seal "gcpckms" {
  project     = "my-gcp-project"
  region      = "global"
  key_ring    = "vault-keyring"
  crypto_key  = "vault-unseal"
}
 
storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
}

Sama seperti AWS, Vault membaca kredensial GCP dari metadata server / default application credentials VM — bukan dari file key yang disimpan di disk. Pastikan VM menjalankan service account yang benar, misalnya saat membuat instance:

gcloud compute instances create vault-node-1 \
  --service-account vault-sa@PROJECT.iam.gserviceaccount.com \
  --scopes https://www.googleapis.com/auth/cloudkms

#Konfigurasi Auto-Unseal dengan Azure Key Vault

Di Azure, alurnya: buat Key Vault dan sebuah Key di dalamnya, berikan akses ke managed identity atau service principal, lalu konfigurasikan Vault:

seal "azurekeyvault" {
  tenant_id      = "11111111-2222-3333-4444-555555555555"
  client_id      = "66666666-7777-8888-9999-000000000000"
  client_secret  = "REDACTED"
  vault_name     = "my-vault-kv"
  key_name       = "vault-unseal"
  environment    = "AZUREPUBLICCLOUD"
}
 
storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
}

Konfigurasi ini menggunakan service principal dengan client_id dan client_secret. Untuk lingkungan yang lebih aman, Azure menyediakan managed identity — Vault bisa mengonfigurasi otentikasi via managed identity dengan menghilangkan client_id/client_secret dan hanya menyediakan tenant_id plus client_id dari managed identity. Service principal ini harus memiliki izin Encrypt, Decrypt, Unwrap Key, dan Wrap Key pada key tersebut (roles Key Vault Crypto Officer atau minimal Key Vault Crypto User untuk dekripsi).

#Init dan Verifikasi: Unseal Keys Menjadi Recovery Keys

Perubahan paling kentara saat menggunakan auto-unseal ada pada proses inisialisasi. Perhatikan, Vault tidak lagi mengeluarkan Unseal Keys, melainkan Recovery Keys:

export VAULT_ADDR=https://10.0.0.11:8200
vault operator init

Unseal Keys        : (none)  ← tidak ada lagi!
Recovery Keys      : 5
Recovery Key 1     : abc...def
Recovery Key 2     : ...
Initial Root Token : hvs.REDACTED

Recovery Keys tidak dipakai untuk unseal rutin — mereka hanya digunakan untuk recovery manual jika akses ke KMS hilang, atau untuk operasi tertentu seperti vault operator generate-root. Karena auto-unseal aktif, Vault langsung terbuka segelnya tanpa intervensi manusia:

vault status

Key             Value
---             -----
Sealed          false
HA Enabled      true

Perhatikan baris Sealed false — padahal tidak ada manusia yang mengetik apa pun. Ini keajaiban auto-unseal: Vault men-dekripsi wrapped root key lewat KMS saat boot. Untuk menjalankan init ulang di seluruh node cluster, cukup unseal dengan Recovery Keys satu kali per node (menggunakan vault operator unseal dengan recovery keys tetap bekerja), atau lebih praktis: karena root key sama, setelah satu node unsealed, node lain bisa ikut terbuka dengan vault operator raft join pada tahap setup.

#Perbandingan Auto-Unseal vs Unseal Manual

Kedua pendekatan punya tempatnya masing-masing. Berikut perbandingan jujurnya:

#Kesalahan Umum (Common Pitfalls)

Area auto-unseal adalah salah satu sumber insiden paling klasik di dunia Vault production:

Poin terakhir perlu ditekankan: auto-unseal memindahkan ketergantungan ke Cloud KMS. Jika KMS down saat Vault perlu reboot, Vault tetap sealed — sama seperti menunggu manusia tadi, hanya bedanya menunggu provider cloud. Untuk produksi, pertimbangkan transit seal atau kombinasi (auto-unseal sebagai primary, recovery keys sebagai prosedur manual darurat yang ditulis di runbook dan dilatih secara berkala).

#Penutup

Pada episode 21 ini kita telah membahas cara menghilangkan unseal manual dari operasional Vault menggunakan auto-unseal dengan tiga cloud provider: AWS KMS, GCP Cloud KMS, dan Azure Key Vault. Kita memahami mekanisme envelope encryption yang membungkus root key dengan KMS key, bagaimana menyiapkan IAM/role dengan prinsip least privilege, perubahan perilaku saat init (Unseal Keys berubah menjadi Recovery Keys), serta perbandingan jujur antara auto-unseal dan manual. Yang tidak kalah penting, kita memetakan kesalahan umum yang bisa membuat Vault terkunci selamanya — dan bagaimana mencegahnya.

Sekarang Vault kalian bisa bangun sendiri setelah reboot dan ber-failover dengan cepat. Tapi tunggu — Vault yang hidup dan tersedia ternyata belum cukup. Bagaimana kita tahu siapa yang mengakses secret apa, kapan, dan dari mana? Bagaimana kita memenuhi tuntutan audit kepatuhan (PCI-DSS, SOC 2) dan melindungi Vault dari sisi host-nya sendiri? Itulah topik besar berikutnya: Audit Logging, Security Hardening & Compliance di episode 22. Pastikan tetap semangat! 🔐