Belajar Vault - Vault Agent & Vault Agent Auto-Auth

#Pendahuluan

Setelah di episode 12 sebelumnya kita membahas bagaimana lease, TTL, renewal, dan revocation bekerja — lengkap dengan alasan mengapa setiap dynamic secret dan token di Vault punya masa hidup terbatas — dan di episode 13 kita membahas cara mengantarkan secret secara aman lewat response wrapping, pada episode kali ini kita akan membahas topik yang paling sering ditunggu para backend developer dan DevOps: bagaimana cara aplikasi mengonsumsi secret dari Vault tanpa harus memprogram seluruh logika autentikasi dan renewal di dalam kode.

Inilah pertanyaan krusialnya: kalau aplikasi kita harus memanggil auth/approle/login, menyimpan token, lalu mengurus renew setiap beberapa menit dan revoke saat proses mati — berarti setiap aplikasi di perusahaan harus menulis ulang kode keamanan yang sama. Itu boilerplate yang rawan salah, rawan bocor, dan mempersulit audit. Solusi HashiCorp untuk masalah ini adalah Vault Agent: sebuah proses pendamping yang mengambil alih semua kerja berat otentikasi dan token lifecycle, sehingga kode aplikasi bisa tetap bersih dan bahkan tidak perlu tahu bahwa Vault itu ada. Yuk kita bedah secara menyeluruh.

#Pembahasan Utama

#Mengapa Vault Agent?

Bayangkan aplikasi kalian seperti seorang karyawan yang butuh masuk ke gedung kantor. Tanpa Vault Agent, karyawan tersebut harus membawa sendiri kartu akses, mengecek masa berlakunya, dan memperpanjang kartunya sendiri sebelum hangus. Sekarang bayangkan ada seratus karyawan dengan ratusan kartu yang berbeda-beda TTL-nya — siapa yang menjamin semuanya diperbarui tepat waktu? Nah, Vault Agent adalah petugas keamanan di depan pintu yang mengurus semua kartu untuk para karyawan.

Secara teknis, manfaat utama Vault Agent adalah:

• Memindahkan tanggung jawab otentikasi dari kode aplikasi ke sebuah daemon terpisah. Kode aplikasi tidak lagi menyimpan VAULT_TOKEN atau logika login.
• Otomatisasi token lifecycle: login ulang saat token kadaluarsa, renewal berkala, dan revoke saat agent berhenti — semua ditangani Vault Agent.
• Merender secret ke file: aplikasi cukup membaca file biasa (.env, config.json, application.yml) yang diisi Vault Agent dari data Vault.
• Konsistensi lintas bahasa: tidak peduli aplikasi ditulis dengan Python, Go, Node.js, atau Java — cara konsumsinya sama: membaca file.

#Konsep Vault Agent Daemon

Vault Agent adalah proses yang berjalan di samping aplikasi (sidecar). Di server VM tradisional ia berjalan sebagai service systemd, di Kubernetes ia berjalan sebagai sidecar container di dalam pod yang sama (akan kita bahas di episode 17). Ia memiliki tiga tanggung jawab utama:

1. Auto-Auth — melakukan login otomatis ke Vault menggunakan auth method mesin (AppRole, AWS, GCP, K8s, dll.) dan memperbarui token secara berkala.
2. Template rendering — membaca secret dari Vault sesuai template Consul Template, lalu menulis hasil render ke file tujuan (sink).
3. Token lifecycle — merenew token sesuai kebijakan Vault, dan membersihkan (revoke) saat proses mati.

Alur kerjanya kira-kira seperti ini:

+-----------+      1. auto-auth (AppRole/AWS/K8s)      +----------------+
|           | ---------------------------------------> |                |
| Vault     | <--------------------------------------- |   Vault Agent  |
| Server    |        2. token + lease                  |    (sidecar)   |
|           |                                           |                |
|           | <--------------------------------------- | 3. template:   |
|           |     4. secret data                       |  secret "..."  |
+-----------+                                           |                |
                                                        | 5. render ke   |
                                                        |    destination |
                                                        +----------------+

Yang perlu digarisbawahi: aplikasi hanya berinteraksi dengan file yang dihasilkan, bukan dengan Vault. Jika Vault sedang down atau token sedang dirotasi, aplikasi tidak ikut terpengaruh karena ia membaca file yang sudah ada di disk.

#Auto-Auth: Login Otomatis yang Mengurus Diri Sendiri

Blok auto_auth di konfigurasi Vault Agent adalah "jantung" dari login otomatis. Di dalamnya kita mendefinisikan:

• method — auth method apa yang dipakai untuk login (misalnya approle, aws, azure, gcp, kubernetes, jwt).
• sink — ke mana token hasil login ditulis. Sink tipe file menulis token ke file, sedangkan aead menulis token dalam keadaan terenkripsi.

Untuk login AppRole, Vault Agent membutuhkan role_id dan secret_id. Keduanya biasanya disimpan di file dengan permission ketat:

pid_file = "/var/run/vault-agent.pid"
 
vault {
  address = "http://127.0.0.1:8200"
}
 
auto_auth {
  method "approle" {
    config = {
      role_id_file_path   = "/etc/vault-agent/role-id"
      secret_id_file_path = "/etc/vault-agent/secret-id"
    }
  }
 
  sink "file" {
    config = {
      path = "/etc/vault-agent/token"
    }
  }
}

Selain AppRole, Auto-Auth juga mendukung otentikasi berbasis cloud: misalnya method aws yang login memakai instance role IAM, atau method kubernetes yang login memakai ServiceAccount JWT. Konsepnya sama — Vault Agent yang mengurus segalanya, kode aplikasi tidak berubah sama sekali. Perbandingan konfigurasi untuk kedua method tersebut:

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    config = {
      role = "web"
      token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
    }
  }
}

auto_auth {
  method "aws" {
    config = {
      type          = "iam"
      role          = "vault-role"
      access_key    = "${file(\"/etc/vault-agent/aws-access-key\")}"
      secret_key    = "${file(\"/etc/vault-agent/aws-secret-key\")}"
    }
  }
}

#Vault Agent Templates & Sink

Bagian paling menarik dari Vault Agent adalah template. Template menggunakan sintaks Consul Template — sebuah bahasa templating Go yang dibekali fungsi secret, withSecret, dan kawan-kawan. Konsepnya: kalian tulis pola file, lalu Vault Agent mengisi bagian secret yang ditandai.

Misalkan secret aplikasi web tersimpan di KV v2 dengan path secret/data/myapp berisi key DB_HOST dan DB_PASSWORD. Template untuk menghasilkan file .env adalah:

APP_ENV=production
APP_PORT=8080
DB_HOST={{ with secret "secret/data/myapp" }}{{ .Data.data.DB_HOST }}{{ end }}
DB_PASSWORD={{ with secret "secret/data/myapp" }}{{ .Data.data.DB_PASSWORD }}{{ end }}

Perhatikan akses datanya: untuk KV v2, data sebenarnya berada di data.data, sehingga variabelnya adalah {{ .Data.data.DB_HOST }}. Untuk KV v1 cukup {{ .Data.DB_HOST }}. Kesalahan memakai level Data yang salah adalah salah satu pitfall paling sering terjadi — akan kita bahas di bagian kesalahan umum.

Blok template di konfigurasi agent menghubungkan template dengan file tujuan:

pid_file = "/var/run/vault-agent.pid"
 
vault {
  address = "http://127.0.0.1:8200"
}
 
auto_auth {
  method "approle" {
    config = {
      role_id_file_path   = "/etc/vault-agent/role-id"
      secret_id_file_path = "/etc/vault-agent/secret-id"
    }
  }
 
  sink "file" {
    config = {
      path = "/etc/vault-agent/token"
    }
  }
}
 
template {
  source      = "/etc/vault-agent/templates/app.env.tpl"
  destination = "/var/lib/myapp/.env"
  perms       = 0600
}

#Menjalankan Vault Agent

Menjalankan Vault Agent cukup sederhana — tunjuk file konfigurasi:

vault agent -config=/etc/vault-agent/config.hcl

Flag -config bisa diulang untuk memuat beberapa file sekaligus — berguna untuk memisahkan konfigurasi per-bagian (misal base.hcl, auto-auth.hcl, templates.hcl) agar mudah di-review:

vault agent -config=/etc/vault-agent/base.hcl \
            -config=/etc/vault-agent/auto-auth.hcl \
            -config=/etc/vault-agent/templates.hcl

Untuk environment production, kita jalankan sebagai service systemd agar selalu hidup dan restart otomatis saat crash. Contoh unit service:

/etc/systemd/system/vault-agent.service

[Unit]
Description=Vault Agent - Secret Rendering Sidecar
Documentation=https://developer.hashicorp.com/vault/docs/agent
Requires=network-online.target
After=network-online.target
 
[Service]
User=vault-agent
Group=vault-agent
ProtectSystem=strict
ExecStart=/usr/bin/vault agent -config=/etc/vault-agent/config.hcl
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
 
[Install]
WantedBy=multi-user.target

Aktifkan dan mulai service

sudo systemctl daemon-reload
sudo systemctl enable --now vault-agent
sudo systemctl status vault-agent

Setelah agent berjalan, file .env akan ter-render. Karena template mengandung secret statis dari KV, Vault Agent merender file tersebut saat pertama kali berhasil login, dan merender ulang setiap kali secret di Vault berubah:

APP_ENV=production
APP_PORT=8080
DB_HOST=postgres.internal.local
DB_PASSWORD=a9f3!sVx#2kQ

#Memahami Siklus Hidup Proses Vault Agent

Agar bisa merancang deployment yang benar, kalian perlu memahami apa yang terjadi pada token di setiap fase proses Vault Agent:

1. Startup — Agent melakukan login via auto-auth, menulis token hasil login ke sink, lalu merender semua template untuk pertama kali. Jika secret yang direferensikan template belum tersedia (misal policy baru saja direvisi), template akan menunggu sampai secret bisa dibaca — file belum ditulis.
2. Operasional — Token di-renew secara otomatis oleh agent sesuai token_ttl. Template dipantau terus; begitu data secret berubah, file hasil render diperbarui. Inilah yang membuat automatic rotation bekerja tanpa aplikasi ikut campur.
3. Reload — Menerima SIGHUP membuat agent memuat ulang konfigurasi (menambah/mengubah template) tanpa memutus token yang sedang aktif.
4. Shutdown — Saat menerima sinyal terminasi (misal systemctl stop), agent melakukan revoke token ke Vault. Ini sangat penting: token tidak dibiarkan hidup mengambang setelah proses mati, menutup kemungkinan penyalahgunaan.

sudo systemctl stop vault-agent
# Log agent: [INFO] (auth.approle) successfully revoked token

#Vault Agent vs In-App SDK

Kapan memakai Vault Agent dan kapan memakai SDK langsung di dalam aplikasi? Keduanya sah, tetapi punya karakteristik berbeda:

Intuisi sederhananya: kalau aplikasi hanya butuh secret statis seperti kredensial koneksi database yang jarang berubah, Vault Agent jauh lebih sederhana dan aman. Tapi jika aplikasi butuh dynamic credentials yang di-generate per request — misalnya kredensial DB baru setiap kali membuka koneksi — maka integrasi SDK langsung adalah pilihan yang tepat. Kedua topik ini akan kita dalami di episode 15 dan 16.

#Kesalahan Umum Vault Agent & Auto-Auth

#Penutup

Pada episode 14 ini kita telah membahas mengapa Vault Agent diperlukan, bagaimana ia bekerja sebagai daemon sidecar, konsep Auto-Auth yang mengotomatiskan login dan token lifecycle, serta Template & Sink untuk merender file konfigurasi (.env, config.json) yang berisi secret dari Vault. Kita juga sudah melihat cara menjalankannya dengan systemd dan memahami perbandingan antara integrasi tidak langsung (agent) vs langsung (SDK).

Inti pelajaran episode ini: kode aplikasi yang tidak perlu tahu tentang Vault adalah kode yang paling aman — semakin sedikit logika keamanan yang tersebar di aplikasi, semakin kecil permukaan serangannya.

Di episode 15 selanjutnya kita akan menggali lebih dalam: Vault Agent Caching untuk mengurangi beban API dan latensi, serta Advanced Templates menggunakan fitur lanjutan Consul Template seperti loop dan kondisional. Pastikan tetap semangat!