Belajar Secret Management - Dynamic Database Secrets Engine (Short-Lived Credentials)
Episode 4 of 21

Belajar Secret Management - Dynamic Database Secrets Engine (Short-Lived Credentials)

Mengubah paradigma kredensial dari statis menjadi dinamis, mengkonfigurasi koneksi PostgreSQL dan MySQL di OpenBao, menulis database roles dengan creation statements dan TTL, serta mengambil kredensial short-lived.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 3 kalian menyimpan secrets statis di KV engine — password aplikasi yang berlaku tanpa batas waktu. Episode 4 ini membawa perubahan paradigma yang lebih besar: dynamic credentials. Alih-alih menyimpan password yang berlaku bertahun-tahun, OpenBao akan membuat user dan password database secara on-demand, berlaku singkat, lalu menghapusnya sendiri.

Ini adalah salah satu fitur paling berdampak di OpenBao, dan di episode ini kalian akan mempraktekkannya langsung dengan PostgreSQL atau MySQL.

Dari Static ke Dynamic Credentials

Untuk memahami nilai dynamic credentials, bandingkan dulu dua pendekatan ini:

AspekStatic CredentialsDynamic Credentials
Masa berlakuTanpa batas atau sangat panjangTTL pendek, misalnya 1 jam
Risiko kebocoranTinggi — sekali bocor, dipakai orang lain dalam waktu lamaRendah — saat bocor, masa berlakunya sudah lewat
PencabutanManual, dan harus tahu semua tempat pemakaianOtomatis oleh OpenBao saat lease kedaluwarsa
RotasiButuh proses dan downtimeTidak perlu — setiap request menghasilkan kredensial baru
Jejak pemakaianSulit dilacakSetiap kredensial punya lease ID yang tercatat

Poin kuncinya: dengan dynamic credentials, tidak ada password yang menunggu lama di server. Ketika sebuah aplikasi butuh akses database, dia meminta ke OpenBao, mendapat kredensial yang hanya berlaku beberapa jam, memakainya, dan kredensial itu menghilang. Jika file konfigurasi bocor ke tempat sampah digital internet, kredensial yang ada di dalamnya sudah tidak berguna.

Menyiapkan Database

Praktik ini membutuhkan database yang bisa dikelola oleh OpenBao — artinya OpenBao harus punya hak untuk membuat dan menghapus role. Di PostgreSQL, siapkan satu user admin khusus untuk OpenBao:

Menyiapkan user untuk OpenBao di PostgreSQL
CREATE ROLE "bao-admin" WITH LOGIN PASSWORD 'strong-admin-password';
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "bao-admin";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO "bao-admin";

User inilah yang akan dipakai OpenBao untuk membuat user-user sementara. Di MySQL, konsepnya serupa: OpenBao membutuhkan user dengan hak CREATE USER, GRANT, dan REVOKE. Prinsip yang sama berlaku — OpenBao menjadi perantara yang mengelola kredensial atas nama aplikasi.

Mengkonfigurasi Koneksi Database di OpenBao

Pertama, aktifkan database secrets engine:

Mengaktifkan database engine
bao secrets enable database
bao secrets list

Kemudian daftarkan koneksi ke database. Di sinilah OpenBao belajar cara mencapai database dan kredensial admin apa yang dipakai:

Mendaftarkan koneksi database
bao write database/config/my-db \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/appdb" \
  username="bao-admin" \
  password="strong-admin-password" \
  allowed_roles="my-role"

bao write database/config/my-db menyimpan konfigurasi koneksi. Bagian allowed_roles="my-role" membatasi role mana yang boleh memakai koneksi ini — keamanan penting agar satu koneksi tidak bisa dipakai untuk role yang tidak berhak. Placeholder username dan password di dalam URL akan digantikan OpenBao secara otomatis.

Setelah koneksi terdaftar, buat role yang mendefinisikan hak akses dan masa berlaku kredensial:

Membuat database role
bao write database/roles/my-role \
  db_name=my-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
  GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

creation_statements adalah SQL yang dijalankan OpenBao setiap kali membuat kredensial baru — perhatikan placeholder name, password, dan expiration yang diisi OpenBao secara otomatis. default_ttl="1h" menetapkan kredensial berlaku satu jam; max_ttl="24h" membatasi perpanjangan maksimum hingga 24 jam.

Important

max_ttl adalah jaring pengaman: meskipun lease diminta diperpanjang berkali-kali, ia tidak akan pernah melewati batas ini. Dengan TTL pendek, blast radius kebocoran kredensial tetap kecil bahkan jika ada bug di aplikasi.

Mengambil Dynamic Credentials

Saat sebuah aplikasi membutuhkan akses database, aplikasi itu cukup meminta kredensial ke role:

Membaca kredensial dinamis
bao read database/creds/my-role

OpenBao langsung mengeksekusi creation statements di PostgreSQL, membuat user sementara, dan mengembalikan hasilnya:

Contoh output kredensial dinamis
Key                Value
---                -----
lease_id           database/creds/my-role/z8lX3e2KcV9WbN...
lease_duration     1h
password           m7xK2pL9qR4sT8vW
username           v-my-role-3fB2dKzL9pR7aA5s

Perhatikan tiga hal penting dari output ini:

  • username — user sementara yang baru saja dibuat di PostgreSQL.
  • password — password acak yang hanya berlaku untuk user ini.
  • lease_id — identitas unik untuk melacak dan mencabut kredensial ini nanti.

Kredensial yang sama tidak pernah terbit dua kali: setiap bao read database/creds/my-role membuat user baru dengan password baru. Inilah esensi short-lived credentials — on-demand, unik, dan otomatis berakhir.

Lease & TTL

Kredensial dinamis hidup dalam kerangka lease: kontrak sementara antara OpenBao dan pemakai. Saat lease berakhir, OpenBao menghapus user di database secara otomatis. Ini berarti:

  • Tanpa perpanjangan, kredensial hilang setelah default_ttl (satu jam di contoh kita).
  • Dengan perpanjangan, masih ada batas keras max_ttl (24 jam).
  • Dengan pencabutan, kredensial bisa dimusnahkan seketika — pembahasan lengkap tentang lease, renewal, dan emergency revocation akan kalian dapatkan di episode 9.

Dari sisi aplikasi, pola yang sehat adalah meminta kredensial, memakai dalam waktu singkat, lalu membiarkannya kadaluarsa — atau meminta ulang secara berkala. Jangan pernah menyimpan kredensial dinamis ke file konfigurasi permanen, karena itu akan menghilangkan seluruh keuntungannya.

Note

Di MySQL, placeholder expiration tidak dikenal seperti di PostgreSQL. Gunakan template yang sesuai dengan plugin database — dokumentasi plugin resmi menyediakan contoh creation statements untuk masing-masing database.

Penutup

Pada episode 4 ini, kalian memahami konsep dynamic credentials yang mengubah cara pandang terhadap kredensial, mengkonfigurasi koneksi database PostgreSQL dan MySQL di OpenBao, menulis database roles dengan creation_statements, default_ttl, dan max_ttl, serta mengambil kredensial short-lived lewat bao read database/creds/my-role.

Inti yang harus dibawa pulang:

  • Dynamic credentials memutus rantai kebocoran — password sementara yang sudah lewat masa berlakunya tidak berguna bagi penyerang.
  • OpenBao butuh hak untuk membuat role — siapkan user admin database khusus untuk OpenBao.
  • TTL adalah pengatur keseimbangandefault_ttl menentukan masa pakai, max_ttl membatasi perpanjangan.
  • Lease ID adalah kunci pengendali — untuk perpanjangan, pencabutan, dan audit setiap kredensial.

Di episode 5 berikutnya kita memasuki dunia Transit Secrets Engine — Encryption-as-a-Service. OpenBao akan menangani enkripsi dan dekripsi data sensitif seperti NIK, nomor kartu kredit, atau data kesehatan melalui API, tanpa pernah menyimpan data tersebut di OpenBao. Kalian akan belajar membuat encryption key, mengenkripsi data dengan base64, dan mendekripsinya kembali — semua dari satu perintah bao. Sampai jumpa di episode 5!

Belajar Secret Management - Dynamic Database Secrets Engine (Short-Lived Credentials) | Belajar Secret Management dengan OpenBao