Belajar Vault - Lease, TTL, Renewal & Revocation (Dynamic Token Lifecycle)

#Pendahuluan

Setelah di episode 11 sebelumnya kita membahas Identity Engine dan bagaimana Vault menyatukan identitas dari berbagai auth method, kita akan masuk ke salah satu keunggulan Vault yang paling membedakannya dari secret manager biasa: siklus hidup setiap akses yang bersifat dinamis dan bisa dihancurkan.

Coba ingat kembali materi dynamic secrets di episode 5: Vault membuat kredensial database on-demand dengan TTL pendek. Sekarang pertanyaan yang lebih dalam: bagaimana Vault mengingat kredensial itu? Kapan ia "mati"? Dan bagaimana kita bisa mematikannya seketika jika terjadi kebocoran? Jawabannya ada pada tiga konsep yang saling berkaitan: Lease, TTL (Time-To-Live), dan Revocation.

Bagi seorang SRE, memahami ini bukan sekadar pengetahuan teoritis. Bayangkan sebuah insiden: credential database produksi bocor di log aplikasi. Dalam sistem tradisional, kalian harus login ke database, menemukan user, dan mencabut aksesnya — bisa berjam-jam. Dengan Vault, satu perintah vault lease revoke menghancurkan kredensial itu dalam hitungan detik. Itulah mengapa topik ini wajib dikuasai sebelum kalian memandu sistem produksi sungguhan.

Mari kita mulai dari konsep Lease.

#Pembahasan Utama

#Apa Itu Lease dan Mengapa Vault Butuh Itu

Lease adalah kontrak waktu antara Vault dan pemegang secret. Setiap kali Vault menerbitkan sesuatu yang "hidup" — dynamic database credentials, dynamic IAM keys, PKI certificates, ataupun token — ia mencatat sebuah lease yang mendefinisikan berapa lama secret itu boleh dipakai.

Mengapa butuh lease? Karena Vault harus punya cara untuk melacak dan mencabut akses yang sudah diberikan. Sekali Vault menerbitkan credential ke database, ia harus bisa menemukan credential itu lagi untuk dicabut saat TTL-nya habis atau saat diperintahkan revoke. Lease ID adalah "tanda terima" unik yang memungkinkan itu semua.

Saat kalian membaca secret ber-lease, perhatikan dua field penting di output:

vault read database/creds/app-db

Key                Value
---                -----
lease_id           database/creds/app-db/Z9wXc8Kv...7Gq
lease_duration     1h
lease_renewable    true
 
Data
----
password           Vp5mQ8sZ...
username           v-app-db-AJ4kLp3R...

• lease_id — identitas unik lease ini, digunakan untuk renew dan revoke.
• lease_duration — berapa lama secret valid (dalam detik; 1h di sini karena default TTL role).
• lease_renewable — apakah lease bisa diperpanjang (true untuk dynamic creds).

Tidak semua secret ber-lease. Static secret di KV tidak punya lease — ia hanya ada sampai kalian mengubah atau menghapusnya. Lease ada pada dynamic output: credential, token, cert, dan semacamnya. Inilah perbedaan fundamental antara "menyimpan rahasia" dan "menerbitkan rahasia".

#TTL: Batas Waktu di Setiap Lapisan

TTL (Time-To-Live) menentukan umur maksimal sebuah lease. Di Vault, TTL bekerja berlapis-lapis, dan TTL efektif adalah yang paling pendek di antara semua lapisan yang berlaku. Berikut lapisan yang paling umum:

Contoh konkret: sebuah role database punya default_ttl=1h dan max_ttl=24h, token yang mengambilnya punya token_ttl=30m. TTL efektif credential-nya adalah 30 menit (nilai terpendek). Pemahaman ini penting agar kalian tidak heran kenapa credential yang konfigurasinya "1 jam" ternyata mati dalam 30 menit.

#Siklus Hidup Lease: Issue → Renew → Expire/Revoke

Sebuah lease melewati beberapa fase:

Issue (read creds)
   │
   ├──► Renew ──► Renew ──► ... ──► Max TTL tercapai / berhenti renew
   │
   └──► Expire (TTL habis) ──► Revoke otomatis credential
   │
   └──► Revoke manual (vault lease revoke) ──► Hancur seketika

1. Issue — lease lahir saat secret dibaca.

vault read database/creds/app-db

2. Renew — perpanjang sebelum kedaluwarsa.

vault lease renew database/creds/app-db/Z9wXc8Kv...7Gq

Key                Value
---                -----
lease_id           database/creds/app-db/Z9wXc8Kv...7Gq
lease_duration     1h
lease_renewable    true

Renew berhasil, dan lease_duration di-reset kembali menjadi 1 jam. Tapi ingat: total renew tidak boleh melewati max_ttl role (24 jam dalam contoh role kita).

3. Expire — TTL habis tanpa renew, Vault mencabut otomatis.

Jika aplikasi tidak pernah renew dan lease mencapai TTL, Vault otomatis mencabut credential di backend (misalnya menghapus user di database PostgreSQL). Aplikasi yang masih memakai credential lama akan mulai mendapat error koneksi.

4. Revoke — pencabutan manual seketika.

vault lease revoke database/creds/app-db/Z9wXc8Kv...7Gq

All revocation operations queued successfully!

#Emergency Revocation: Menghancurkan Akses dalam Hitungan Detik

Inilah momen yang paling penting secara operasional. Ketika credential bocor — misalnya terdorong ke GitHub, kehilangan keylogger, atau muncul di log publik — kalian harus mencabut akses seketika, bukan menunggu TTL. Vault menyediakan beberapa level pencabutan:

1. Revoke satu lease spesifik

vault lease revoke database/creds/app-db/Z9wXc8Kv...7Gq

2. Revoke semua lease di bawah prefix — the kill switch

vault lease revoke -prefix database/creds/

All revocation operations queued successfully!

Perintah di atas menghancurkan seluruh credential database yang pernah diterbitkan dari mount database/ — semua aplikasi yang memakai dynamic credentials akan terputus seketika dan harus mengambil yang baru. Ini adalah senjata nuklir untuk menanggulangi kebocoran massal.

3. Revoke berdasarkan role

vault lease revoke -prefix database/creds/app-db

4. Revoke seluruh token dan lease turunannya

vault token revoke hvs.CAESILf...

vault token revoke -mode=all -accessor <accessor>

#Pola Renewal Otomatis di Aplikasi

Secret ber-TTL pendek berarti aplikasi harus melek lifecycle: renew sebelum habis, atau re-login jika sudah terlanjur habis. Ada tiga pola umum:

Aturan praktis yang umum: perbarui lease di sekitar 67% dari TTL — bukan menunggu mendekati habis, karena renew yang gagal tepat sebelum expiry berisiko membuat aplikasi memakai credential mati. Contoh ilustrasi sederhana dalam sebuah loop:

TTL = 1 jam
while lease masih aktif:
    sleep TTL * 2/3          # tidur 40 menit
    vault lease renew $LEASE_ID

Ketika renew terakhir ditolak (karena max TTL tercapai), aplikasi seharusnya mengambil credential baru, bukan memaksa memakai yang lama:

vault read database/creds/app-db

Pola ini akan menjadi otomatis dan rapi dengan Vault Agent di episode 14 dan 15, tapi pemahaman manual di episode ini membuat kalian mengerti apa yang sebenarnya Agent lakukan di balik layar.

#Skenario Insiden: Kebocoran Credential Production

Mari kita latih refleks kalian dengan skenario nyata. Pukul 03.00, monitoring mengirimkan alert: sebuah credential database dengan username v-app-db-AJ4kLp3R... muncul di log publik sebuah layanan logging pihak ketiga.

Langkah yang benar (berurutan):

1. Revoke dulu — jangan panik memikirkan diagnosis.

vault lease revoke database/creds/app-db/Z9wXc8Kv...7Gq

2. Cabut token yang menjadi sumbernya (jika diketahui).

vault token revoke hvs.CAESILf...

3. Rotasi kredensial yang tersisa di bawah prefix yang sama.

vault lease revoke -prefix database/creds/app-db

4. Verifikasi di backend: user database sudah tidak ada.

SELECT usename FROM pg_user WHERE usename LIKE 'v-app-db-%';

5. Biarkan aplikasi mengambil kredensial baru, lalu audit.

Karena credential-nya dynamic, aplikasi cukup membaca lagi database/creds/app-db dan ia mendapat user baru yang sehat. Tidak ada password lama yang harus diubah manual, tidak ada downtime yang panjang. Inilah bedanya secret management dengan password static.

#Melacak Lease yang Masih Aktif: vault lease list

Dalam sistem produksi, jumlah lease yang aktif bisa mencapai ribuan. Kemampuan memantau mereka sangat penting untuk menjaga backend tetap sehat dan memastikan tidak ada "lease yatim" (orphaned lease) yang menumpuk.

vault lease list -prefix database/creds/

Keys
----
database/creds/app-db/Z9wXc8Kv...7Gq
database/creds/app-db/Aj8Lm4Rt...2Xb
database/creds/analytics/Kp1Qs6Wd...9Nc

Dengan vault lease list kalian bisa melihat semua lease yang masih tercatat di mount tertentu, memeriksa kebersihannya, dan mengidentifikasi apakah ada kredensial yang lupa di-revoke setelah aplikasinya di-shutdown. Lease yang terus bertambah tanpa pernah berkurang adalah gejala bahwa aplikasi memakai pola "ambil credential tapi tidak pernah revoke" — tidak fatal secara langsung karena TTL akan menghabisinya, tapi tetap memboroskan resource backend (misalnya user database yang terus dibuat).

#Hubungan Token dan Lease: Revoke Token = Revoke Subtree

Token dan lease saling terhubung dalam hierarki. Ketika sebuah token diterbitkan dari token lain (misal aplikasi login AppRole menghasilkan token, lalu token itu membuat token tambahan untuk proses lain), semua token turunan serta lease yang mereka hasilkan adalah bagian dari satu subtree.

Revoke pada token induk memiliki efek berantai:

vault token revoke hvs.CAESILf...

Output-nya akan mencantumkan bahwa revocation di-antrikan untuk semua lease turunan:

All revocation operations queued successfully!

Inilah alasan mengapa memakai token per-aplikasi (bukan token bersama) itu penting: ketika sebuah aplikasi dianggap terkontaminasi, kalian cukup revoke token-nya, dan semua kredensial yang dihasilkan melalui token tersebut ikut hancur. Satu pintu, seluruh kuncinya ikut rusak.

#Kesalahan Umum dalam Lease, TTL & Revocation

#Penutup

Pada episode ini kita telah membahas Lease, TTL, Renewal & Revocation: konsep lease sebagai kontrak waktu untuk setiap secret dinamis, lapisan-lapisan TTL yang saling membatasi, cara memperpanjang lease dengan vault lease renew, serta pencabutan akses instan dengan vault lease revoke — baik per lease maupun per prefix. Kita juga mempelajari pola renewal otomatis dan urutan langkah saat insiden kebocoran credential.

Inti dari episode ini: keunggulan terbesar Vault bukan hanya menyimpan secret, tapi kemampuannya membuat secret "hidup" (ber-TTL) dan menghancurkannya seketika. Sebagai SRE, kemampuan revoke inilah yang mengubah insiden kredensial dari mimpi buruk multi-jam menjadi operasi satu menit.

Di episode 13 selanjutnya, kita akan membahas bagaimana mengirimkan secret — termasuk SecretID AppRole — ke server baru dengan aman: Response Wrapping & Cubbyhole untuk pengiriman secret tanpa transit plaintext. Pastikan tetap semangat!