Belajar PKI - Vault PKI Engine (HashiCorp Vault)

#Pendahuluan

Di episode 11 kalian melihat CFSSL, toolkit yang melayani PKI lewat utilitas dan API sederhana. Episode ini membawa pendekatan yang jauh lebih lengkap: HashiCorp Vault, alat manajemen rahasia yang di dalamnya terdapat PKI engine. Alih-alih alat khusus PKI, Vault menyimpan banyak jenis rahasia — token, kredensial database, hingga sertifikat — dengan satu kebijakan akses terpusat.

Kekuatan PKI engine Vault terletak pada pola penggunaannya: kalian mendefinisikan role, lalu meminta sertifikat lewat perintah atau API. Vault mengelola kunci CA, menerbitkan sertifikat, mencatat setiap penerbitan, dan menyediakan CRL serta OCSP. Semua transaksi tercatat di audit log.

Roadmap episode ini: kita mount PKI engine, susun arsitektur root dan intermediate, buat role, terbitkan sertifikat, atur masa berlaku, kelola CRL dan OCSP, lalu integrasikan dengan step-ca dan aplikasi melalui consul-template dan Vault Agent.

#Konsep PKI Engine di Vault

Vault memperlakukan CA sebagai secrets engine dengan jalur tertentu, biasanya pki untuk root dan pki_int untuk intermediate. Setiap engine punya kunci privatnya sendiri, kebijakan masa berlaku, dan CRL terpisah. Dengan memisahkan jalur, satu instance Vault bisa menampung beberapa CA sekaligus.

Setiap engine memiliki serangkaian endpoint untuk tugas berbeda: membuat kunci CA, menandatangani intermediate, menerbitkan sertifikat, mencabut sertifikat, dan membaca CRL. Akses ke endpoint ini diatur lewat kebijakan Vault biasa, sehingga hanya pihak tertentu yang boleh menerbitkan.

#Arsitektur Root dan Intermediate

Praktik terbaik yang sama seperti episode 2 tetap berlaku: root CA dibawa offline atau dipegang sangat ketat, sedangkan intermediate yang melayani permintaan sehari-hari. Di Vault, root dan intermediate hidup sebagai dua engine berbeda di instance yang sama atau terpisah.

#Membuat Root CA

Root dibuat dengan generate internal. Vault membuat kunci dan sertifikat root sekaligus menyimpannya.

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki

Masa berlaku root dibuat sangat panjang, misalnya sepuluh tahun, karena root jarang dirotasi. Kunci root di engine pki harus dijaga dengan kebijakan akses yang ketat.

#Membuat Intermediate

Intermediate diletakkan di engine terpisah bernama pki_int. Kuncinya digenerate di engine tersebut, lalu CSR-nya ditandatangani oleh root.

vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int

Setelah langkah ini, pki_int siap menerbitkan sertifikat sebagai CA yang sah, di bawah naungan root. Pola ini menjaga kunci root tetap minim dipakai.

#Penerbitan Berbasis Role

Vault tidak menerima permintaan sertifikat sembarangan. Semua penerbitan lewat role yang mendefinisikan domain yang diizinkan, tipe kunci, dan masa berlaku maksimal. Ini adalah kunci keamanan PKI engine.

#Membuat Role

create-role.sh

vault write pki_int/roles/web-service \
  allowed_domains=internal.example.com \
  allow_subdomains=true \
  max_ttl=2160h \
  key_type=ec \
  key_bits=256

Role web-service hanya mengizinkan nama di bawah internal.example.com. Nama lain ditolak Vault. max_ttl membatasi masa berlaku paling panjang yang bisa diminta.

#Meminta Sertifikat

Penerbitan dilakukan dengan menulis ke endpoint issue diikuti nama role.

issue-cert.sh

vault write pki_int/issue/web-service \
  common_name=api.internal.example.com \
  ttl=2160h

vault write pki_int/issue/web-service mengembalikan sertifikat, kunci privat, dan rantai CA dalam satu respons. Perhatikan bahwa kunci privat dihasilkan Vault sendiri, sehingga aplikasi harus menyimpannya dengan hati-hati sebelum dipakai.

Selain issue, ada sign untuk menandatangani CSR yang datang dari luar, dan generate untuk membuat kunci sekaligus sertifikat. Pilih sesuai kebutuhan: issue paling nyaman untuk aplikasi baru, sign lebih cocok bila kunci sudah dibuat di tempat lain.

#Certificate Lifetime dan Rotasi

Masa berlaku sertifikat ditentukan tiga lapis: batas engine, batas role, dan nilai yang diminta. Vault selalu mengambil nilai yang paling kecil. Dengan max_ttl pada role dan ttl pada permintaan, kalian bisa menegakkan kebijakan seperti sertifikat maksimal 90 hari.

Vault tidak memperbarui sertifikat secara otomatis. Perpanjangan terjadi ketika aplikasi meminta lagi lewat issue atau ketika klien seperti Vault Agent melakukan renewal. Inilah mengapa integrasi dengan tool otomatis sangat penting.

#OCSP dan CRL

Vault mencatat setiap sertifikat yang diterbitkan dan mencabut sertifikat ketika diminta. CRL tersedia lewat endpoint khusus dan diperbarui otomatis sesuai interval yang ditetapkan.

read-crl.sh

vault read pki_int/crl/pem

revoke-cert.sh

vault write pki_int/revoke serial_number=12:34:56:78

vault write pki_int/revoke mencabut sertifikat dan mencantumkannya di CRL. Vault juga menyediakan OCSP responder sehingga aplikasi bisa memeriksa status sertifikat secara realtime. Sertifikat yang dicabut tidak bisa kembali aktif.

#Integrasi dengan step-ca

step-ca dan Vault bukan lawan, melainkan bisa digabung. Skenario umum: Vault menjadi CA utama, sedangkan step-ca melayani permintaan ACME di lingkungan yang membutuhkannya. Melalui plugin step-kms dari HashiCorp, step-ca bisa menyimpan kunci CA-nya di Vault Transit sehingga kunci privat tidak pernah keluar dari Vault.

Pilihan antara keduanya bergantung konteks. Jika tim kalian sudah memakai Vault untuk rahasia lain, PKI engine-nya adalah langkah alami. Jika kebutuhan utama adalah ACME dan SSH, step-ca lebih langsung. Keduanya sama-sama mampu, dan memahami keduanya membuat kalian fleksibel.

#Integrasi dengan Aplikasi

Sertifikat yang diterbitkan harus sampai ke aplikasi dengan aman. Dua cara paling umum: consul-template dan Vault Agent.

#consul-template

consul-template merender template dari nilai yang diambil Vault, lalu menulis hasilnya ke file. Sertifikat diperbarui ketika masa berlakunya mendekati akhir.

cert.tpl

{{ with secret "pki_int/issue/web-service" "common_name=api.internal.example.com" }}
{{ .Data.certificate }}
{{ .Data.private_key }}
{{ end }}

Template ini meminta sertifikat lewat role web-service, lalu menulis sertifikat dan kunci privat ke lokasi yang kalian tentukan. Ketika Vault mengindikasikan perpanjangan, consul-template menulis ulang file dan memberi tahu service.

#Vault Agent

Vault Agent bekerja serupa tanpa memerlukan template eksternal. Ia mengambil sertifikat, menulis ke sink, lalu memperbarui otomatis sebelum kedaluwarsa.

agent.hcl

vault {
  address = "https://vault.internal:8200"
}
 
template {
  source      = "/etc/agent/cert.tpl"
  destination = "/etc/tls/server.crt"
}
 
template {
  source      = "/etc/agent/key.tpl"
  destination = "/etc/tls/server.key"
}

Dengan pola ini, aplikasi tidak perlu mengerti API Vault sama sekali. Ia hanya membaca file di direktori tertentu, dan file itu selalu segar berkat Vault Agent.

#Penutup

Episode 12 memperkenalkan PKI engine Vault sebagai pendekatan terpusat untuk manajemen sertifikat. Kalian melakukan mount engine, membangun arsitektur root dan intermediate, membuat role untuk penerbitan terkontrol, mengatur masa berlaku, mengelola OCSP dan CRL, menggabungkannya dengan step-ca, dan menghubungkan aplikasi lewat consul-template serta Vault Agent.

Inti yang harus dibawa pulang:

PKI engine Vault memperlakukan CA sebagai jalur rahasia dengan kebijakan akses terpusat.
Arsitektur root dan intermediate diterapkan dengan memisahkan engine pki dan pki_int.
Role membatasi domain, tipe kunci, dan masa berlaku yang bisa diminta.
vault write pki_int/issue berperan sebagai pintu penerbitan berbasis role.
CRL dan OCSP dikelola otomatis Vault, lengkap dengan audit log.
consul-template dan Vault Agent mengotomatiskan distribusi dan renewal ke aplikasi.

Di episode 13 kita membahas bagian paling sensitif: kunci privat. Kalian akan belajar keamanan berbasis file, kunci berpassphrase, HSM dan PKCS#11 dengan YubiKey PIV serta TPM, image HSM step-ca, KMS seperti AWS KMS dan Azure Key Vault, hingga split knowledge. Sampai jumpa!