Belajar Vault - Integrasi Vault dengan Infrastructure as Code (IaC - Terraform & Ansible)

#Pendahuluan

Setelah di episode 18 sebelumnya kita membahas bagaimana pipeline CI/CD meminjam kredensial sementara dari Vault alih-alih menyimpan API key permanen, pada episode kali ini kita akan menerapkan filosofi yang sama pada lapisan yang lebih fundamental: infrastruktur itu sendiri. Kita akan membahas integrasi Vault dengan dua tool IaC paling populer di industri — Terraform dan Ansible.

Kenapa topik ini begitu penting? Karena selama ini, ada ironi besar di dunia IaC: kita mengotomatisasi pembuatan server, jaringan, dan database, tapi kredensial yang dibutuhkan infrastruktur itu sendiri masih di-hardcode atau disimpan di file konfigurasi. Contoh nyata: sebuah module Terraform yang membuat database PostgreSQL lalu menyimpan password admin-nya sebagai variabel plaintext di repository — dan lebih parah lagi, password itu ikut tersimpan selamanya di terraform state file. Atau playbook Ansible yang menulis kredensial statis ke /etc/myapp/config.yml di ribuan server tanpa mekanisme rotasi.

Dengan integrasi Vault, pola yang benar berubah total: infrastruktur meminta kredensialnya kepada Vault pada saat provisioning, dan kredensial itu lahir dengan masa hidup terbatas. Database yang dibuat Terraform bisa menggunakan dynamic credentials yang hangus dalam hitungan jam. Sertifikat TLS internal untuk aplikasi bisa diterbitkan on-demand dengan TTL 24 jam dan dirotasi otomatis. Dan server yang diatur Ansible tidak pernah menyimpan secret di disk — ia membaca langsung dari Vault setiap kali playbook dijalankan. Mari kita bahas satu per satu.

#Pembahasan Utama

#Mengapa IaC Membutuhkan Integrasi Vault

Sebelum masuk ke kode, mari kita bedah tiga masalah utama yang dipecahkan integrasi ini:

Intinya: Vault memutus siklus "secret yang menetap". Terraform dan Ansible tetap menjadi source of truth untuk infrastruktur, tapi Vault menjadi source of truth untuk kredensialnya.

#Terraform: Vault Provider

HashiCorp menyediakan provider resmi hashicorp/vault untuk Terraform. Ada tiga kemampuan utama yang akan kita pakai:

1. Membaca secret — mengambil nilai dari Vault saat provisioning (data sources).
2. Menerbitkan kredensial — dynamic database credentials dan sertifikat PKI dengan TTL pendek (data sources).
3. Menulis data — membuat secret, mount, dan mengonfigurasi secrets engine (resources).

#Konfigurasi Provider & Autentikasi

Provider Vault perlu tahu alamat server dan cara login. Di environment produksi, jangan pernah menaruh token di kode — gunakan blok auth_login dengan AppRole, atau biarkan provider membaca VAULT_TOKEN dari environment:

provider "vault" {
  address = var.vault_addr
 
  auth_login {
    path = "auth/approle/login"
    params = {
      role_id   = var.vault_role_id
      secret_id = var.vault_secret_id
    }
  }
}
 
variable "vault_addr" {
  default = "https://vault.example.com:8200"
}
 
variable "vault_role_id" {}
variable "vault_secret_id" {}

Nilai vault_role_id dan vault_secret_id sebaiknya di-pass lewat variabel environment (TF_VAR_vault_role_id) atau diambil dari pipeline CI/CD yang sudah kita bangun di episode 18 — bukan ditulis di terraform.tfvars.

#Membaca Secret KV: vault_kv_secret_v2 vs vault_generic_secret

Untuk membaca secret dari KV secrets engine, pilihan data source bergantung pada versi engine:

data "vault_kv_secret_v2" "app" {
  mount = "kv"
  name  = "ci/app"
}
 
# Akses nilai: data.vault_kv_secret_v2.app.data["DB_PASSWORD"]

data "vault_generic_secret" "app" {
  path = "secret/app"
}
 
# Akses nilai: data.vault_generic_secret.app.data["DB_PASSWORD"]

vault_kv_secret_v2 adalah pilihan yang disarankan karena mendukung versioning, metadata, dan rollback — fitur yang kita bahas di episode 4. Contoh penggunaan nyata: mengisi password aplikasi ke resource database yang dibuat Terraform:

data "vault_kv_secret_v2" "app" {
  mount = "kv"
  name  = "postgres/app"
}
 
resource "aws_db_instance" "app_db" {
  identifier     = "app-db"
  engine         = "postgres"
  instance_class = "db.t3.micro"
 
  username = data.vault_kv_secret_v2.app.data["DB_USERNAME"]
  password = data.vault_kv_secret_v2.app.data["DB_PASSWORD"]
 
  skip_final_snapshot = true
}

#Dynamic Database Credentials: vault_database_creds

Ini adalah fitur yang membuat integrasi Vault+Terraform sangat kuat. Alih-alih membaca password statis dari KV, kita bisa meminta Vault untuk membuat kredensial database baru yang hangus otomatis:

data "vault_database_creds" "app" {
  backend = "database"
  role    = "deploy-reader"
}
 
# Username & password dinamis, valid selama TTL role
resource "aws_db_instance" "app_db" {
  ...
  username = data.vault_database_creds.app.username
  password = data.vault_database_creds.app.password
}

Setiap kali terraform apply dijalankan, Vault membuat user baru di PostgreSQL/MySQL dengan privilege sesuai role (misalnya deploy-reader), lalu menghapusnya otomatis setelah lease berakhir. Ini paradigma dari episode 5 yang diterapkan ke IaC: kredensial yang bocor = kredensial yang sudah tidak berlaku.

#Sertifikat PKI: vault_pki_secret

Pola yang sama berlaku untuk sertifikat TLS internal (episode 7). Terraform bisa menerbitkan sertifikat dari Vault PKI dengan TTL pendek saat membuat resource yang membutuhkannya:

data "vault_pki_secret" "app_cert" {
  backend     = "pki_int"
  name        = "internal-app"
  common_name = "api.internal.example.com"
  alt_names   = ["api.internal.example.com"]
  ttl         = "24h"
}
 
resource "aws_lb_listener" "app" {
  load_balancer_arn = aws_lb.app.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS-1-2-2017-01"
 
  certificate_arn = data.vault_pki_secret.app_cert.cert_chain
}

Karena TTL-nya pendek, Terraform akan secara otomatis menerbitkan sertifikat baru saat data source diperbarui (misalnya setiap plan/apply ulang). Ini memaksa rotasi berkala tanpa manusia — justru menghilangkan masalah "sertifikat kedaluwarsa di malam hari" yang kita bahas di episode 7.

#Menulis Data ke Vault dari Terraform

Terraform juga bisa menjadi manager untuk Vault itu sendiri — membuat mount, menulis KV secret, dan mengonfigurasi secrets engine. Contoh: membuat mount kv (KV v2) dan menulis secret bootstrap aplikasi:

resource "vault_mount" "kv" {
  path        = "kv"
  type        = "kv-v2"
  description = "KV v2 untuk secret aplikasi"
}
 
resource "vault_kv_secret_v2" "bootstrap" {
  mount = vault_mount.kv.path
  name  = "postgres/app"
 
  data_json = jsonencode({
    DB_USERNAME = "app_user"
    DB_PASSWORD = random_password.app_password.result
  })
}
 
resource "random_password" "app_password" {
  length  = 24
  special = true
}

Perhatikan pola menarik di atas: password dibuat oleh random_password resource, ditulis ke Vault, dan tidak pernah muncul sebagai literal di kode. Resource lain (misalnya EC2 user-data atau secret untuk pipeline) tinggal membaca dari Vault. Inilah chicken-and-egg bootstrap yang rapi: Vault dikonfigurasi dan diisi oleh Terraform, kemudian Terraform lain membaca dari Vault.

#Ansible: Lookup Plugin community.hashi_vault

Ansible menangani lapisan berbeda dari Terraform: Terraform membuat infrastruktur, Ansible mengonfigurasi server yang sudah ada. Untuk mengambil secret dari Vault saat playbook berjalan, kita menggunakan collection resmi community.hashi_vault, yang menyediakan lookup plugin hashi_vault dan sejumlah module (vault_read, vault_write, dan lain-lain).

Pertama, pastikan collection terpasang:

ansible-galaxy collection install community.hashi_vault

#Mengambil Secret dengan Lookup Plugin

Lookup plugin dievaluasi saat task berjalan, jadi nilainya selalu segar dari Vault — bukan dari cache file. Contoh sederhana dengan autentikasi AppRole:

- name: Ambil secret dari Vault
  hosts: app-servers
  vars:
    vault_url: "https://vault.example.com:8200"
    vault_role_id: "{{ lookup('env', 'VAULT_ROLE_ID') }}"
    vault_secret_id: "{{ lookup('env', 'VAULT_SECRET_ID') }}"
  tasks:
    - name: Baca kredensial database dari Vault
      ansible.builtin.set_fact:
        db_password: "{{ lookup('community.hashi_vault.hashi_vault',
          'kv/data/postgres/app',
          url=vault_url,
          auth_method='approle',
          role_id=vault_role_id,
          secret_id=vault_secret_id,
          mount_point='kv')['data']['data']['DB_PASSWORD'] }}"
 
    - name: Tulis konfigurasi aplikasi
      ansible.builtin.template:
        src: app.config.j2
        dest: /etc/myapp/config.yaml
        mode: "0600"

Bedah bagian penting:

• Path kv/data/postgres/app — seperti pada episode sebelumnya, KV v2 butuh segmen data/. Parameter mount_point='kv' memberi tahu plugin di mount mana path itu berada.
• ['data']['data']['DB_PASSWORD'] — lookup mengembalikan response JSON penuh dari Vault. Untuk KV v2, respons berstruktur data.data.<field>; jangan lupa lapisan ganda ini.
• role_id dan secret_id diambil dari environment — bukan di-hardcode di playbook atau di grup inventory. Ini mencegah kredensial ikut tercommit ke repository Ansible.

#Pendekatan Lebih Bersih dengan Module vault_read

Untuk kejelasan dan kemampuan pengendalian error, gunakan module vault_read daripada lookup. Module bisa di-register dan hasilnya direferensikan, plus lebih mudah di-debug:

- name: Baca secret dari Vault (module)
  community.hashi_vault.vault_read:
    url: "https://vault.example.com:8200"
    auth_method: approle
    role_id: "{{ vault_role_id }}"
    secret_id: "{{ vault_secret_id }}"
    path: kv/data/postgres/app
  register: vault_result
  no_log: true
 
- name: Simpan nilai sebagai fact
  ansible.builtin.set_fact:
    db_username: "{{ vault_result.data.data.DB_USERNAME }}"
    db_password: "{{ vault_result.data.data.DB_PASSWORD }}"
 
- name: Jalankan aplikasi dengan secret dari Vault
  ansible.builtin.systemd:
    name: myapp
    state: restarted
  environment:
    DB_USERNAME: "{{ db_username }}"
    DB_PASSWORD: "{{ db_password }}"

Dua detail krusial di sini:

• no_log: true pada task yang berinteraksi dengan secret — memastikan nilai rahasia tidak pernah muncul di output Ansible meskipun kalian menjalankan ansible-playbook -vvv.
• Secret disuntikkan lewat environment: pada task tertentu saja, tidak ditulis permanen ke file config — kecuali memang dibutuhkan oleh proses yang berjalan lama, dan itupun sebaiknya dengan permission yang ketat.

#Perbandingan: Terraform vs Ansible

Kedua tool melengkapi satu sama lain, bukan bersaing. Berikut perbandingannya:

Pola terbaik di produksi adalah kombinasi keduanya: Terraform membuat infrastruktur dan mengisi Vault (bootstrap), Ansible mengonfigurasi server dengan membaca dari Vault, dan Vault Agent menjaga secret tetap segar di masa hidup server.

#Kesalahan Umum (Common Pitfalls) IaC + Vault

Terakhir, mari kita bahas jebakan yang paling sering membuat tim jatuh:

#Penutup

Pada episode 19 ini kita telah membahas bagaimana Terraform dan Ansible — dua tulang punggung IaC — bisa berintegrasi dengan Vault untuk memutus siklus secret yang menetap. Dengan Terraform Vault Provider, infrastruktur bisa menerbitkan kredensial database dinamis dan sertifikat PKI on-demand saat provisioning, sekaligus menulis dan mengonfigurasi data di Vault secara deklaratif. Dengan Ansible, server yang sudah ada bisa membaca secret langsung dari Vault lewat lookup plugin atau module vault_read, tanpa pernah menyimpan kredensial di disk.

Poin kunci yang perlu kalian bawa pulang:

• Terraform menggunakan data sources (vault_kv_secret_v2, vault_database_creds, vault_pki_secret) untuk membaca, dan resources (vault_mount, vault_kv_secret_v2) untuk menulis ke Vault.
• Ansible memakai community.hashi_vault dengan lookup hashi_vault atau module vault_read; selalu gunakan no_log: true pada task sensitif.
• Secret di tfstate bukanlah rahasia — gunakan remote state terenkripsi dan prioritaskan kredensial dinamis.
• Jangan pernah commit RoleID/SecretID; ambil dari environment atau pipeline.

Kita sudah membahas integrasi dengan aplikasi, Kubernetes, CI/CD, dan IaC. Di episode 20 selanjutnya, kita akan naik ke level arsitektur: Vault High Availability (HA) Cluster dengan Raft Integrated Storage — bagaimana membangun cluster 3-node atau 5-node yang tidak punya titik tunggal kegagalan, lengkap dengan vault operator raft join dan pemilihan leader. Pastikan tetap semangat!