Belajar Vault - Studi Kasus Complete Production-Grade Vault Architecture

#Pendahuluan

Setelah di episode 24 sebelumnya kita membangun observability dan troubleshooting — sehingga Vault kita tidak hanya aman dan tersedia, tapi juga bisa diamati — pada episode kali ini, episode terakhir dari seri Belajar Secret Management dengan HashiCorp Vault, kita akan merangkai seluruh perjalanan kalian menjadi satu kesatuan: arsitektur Vault enterprise production-grade end-to-end.

Perjalanan ini dimulai di episode 0 dengan pertanyaan sederhana: "apa itu secret management dan mengapa dunia butuh Vault?" Dua puluh lima episode kemudian, kalian tidak lagi bertanya apa — melainkan bagaimana merancang sistem secret management yang hidup, aman, terukur, dan bisa dioperasikan di skala organisasi. Di antara keduanya, kalian telah mempelajari arsitektur dan unsealing, secrets engines (KV, dynamic database, Transit, PKI, TOTP/SSH/AWS), autentikasi dan otorisasi, identitas, leases, response wrapping, integrasi dengan aplikasi dan Kubernetes, CI/CD dan IaC, hingga HA, auto-unseal, hardening, multi-tenancy, dan observability.

Semua keterampilan itu selama ini terasa terpisah-pisah. Di dunia kerja nyata, mereka berjalan sebagai satu sistem. Episode ini akan merancang satu arsitektur untuk sebuah perusahaan fiksi — sebut saja PT Nusantara Fintech — yang ingin mengamankan seluruh secret-nya dengan Vault: infrastruktur cloud, aplikasi di Kubernetes, database, data PII pelanggan, sampai akses manusia. Ini bukan episode tentang fitur — ini episode tentang cara berpikir seorang security/platform engineer saat merancang secret management yang sesungguhnya.

#Pembahasan Utama

#Gambaran Besar Arsitektur: PT Nusantara Fintech

Kita akan merancang sistem dengan lima lapisan yang saling terhubung:

1. Infrastructure Layer — 3-node Vault HA cluster (Raft + AWS KMS auto-unseal + TLS).
2. Kubernetes Integration — Vault Agent Sidecar Injector + Kubernetes Auth di EKS.
3. Database Security — dynamic credentials PostgreSQL dengan TTL pendek.
4. Application Security — Transit engine untuk enkripsi PII (NIK / nomor kartu kredit).
5. Human Access & Governance — OIDC via Okta, audit log ke Grafana Loki, snapshot harian.

Berikut alur request end-to-end pada arsitektur ini:

Peta setiap komponen ke episode asalnya:

#Layer 1: Infrastructure — Cluster HA + Auto-Unseal + TLS

Fondasi arsitektur adalah 3-node Vault HA cluster dengan Raft (episode 20), AWS KMS auto-unseal (episode 21), dan TLS wajib (episode 22). Server config per node:

seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "1234abcd-5678-90ef-ghij-klmnopqrstuv"
}
 
storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.12:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.13:8200"
  }
}
 
listener "tcp" {
  address         = "0.0.0.0:8200"
  tls_disable     = false
  tls_cert_file   = "/etc/vault.d/tls/vault.crt"
  tls_key_file    = "/etc/vault.d/tls/vault.key"
  tls_min_version = "tls12"
}
 
api_addr     = "https://10.0.0.11:8200"
cluster_addr = "https://10.0.0.11:8201"
disable_mlock = false
 
telemetry {
  prometheus_retention_time = "24h"
  disable_hostname          = true
}

Keputusan arsitektural pada layer ini:

• 3 node — satu node mati tetap aman (quorum 2), sesuai tabel toleransi episode 20.
• AWS KMS auto-unseal — tidak ada unseal manual; Recovery Keys 3-of-5 disimpan terpisah sebagai rencana darurat.
• TLS + disable_mlock = false — traffic terenkripsi, kunci tidak bisa di-swap ke disk.
• Telemetry aktif — siap di-scrape Prometheus (episode 24).

#Layer 2: Kubernetes Integration — Agent Injector + K8s Auth

Aplikasi backend PT Nusantara Fintech berjalan di EKS. Pod tidak memegang secret sama sekali — ia mendapatkan secret lewat Vault Agent Sidecar Injector (episode 17) yang diotomasi lewat annotations. Yang perlu disiapkan terlebih dahulu: mengaktifkan Kubernetes auth method di Vault dan menulis policy untuk service account aplikasi.

vault auth enable kubernetes
 
vault write auth/kubernetes/config \
  kubernetes_host="https://EKS_CLUSTER_ENDPOINT:443" \
  token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
 
vault write auth/kubernetes/role/backend \
  bound_service_account_names=backend-sa \
  bound_service_account_namespaces=backend \
  policies=backend-k8s \
  ttl=1h

path "database/creds/backend-role" {
  capabilities = ["read"]
}

Setelah itu, deployment Pod cukup ditambahkan annotations untuk memicu injector:

deployment.yaml - annotations injector

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  namespace: backend
spec:
  replicas: 3
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "backend"
        vault.hashicorp.com/agent-inject-secret-dbcreds: "database/creds/backend-role"
        vault.hashicorp.com/agent-inject-template-dbcreds: |
          {{- with secret "database/creds/backend-role" -}}
          DB_HOST={{ .Data.host }}
          DB_USER={{ .Data.username }}
          DB_PASSWORD={{ .Data.password }}
          {{- end -}}
    spec:
      serviceAccountName: backend-sa
      containers:
        - name: backend-api
          image: nusantara/backend-api:1.4.2
          env:
            - name: DB_CONFIG
              value: /vault/secrets/dbcreds

Hasilnya: Pod boot, injector memasang container Vault Agent sebagai sidecar, Agent melakukan login via K8s auth, mengambil dynamic credentials database, dan merendernya ke file /vault/secrets/dbcreds (episode 14 & 17). Aplikasi membaca file tersebut — tanpa menyentuh Vault API sama sekali, tanpa token di kode.

#Layer 3: Database Security — Dynamic PostgreSQL Credentials

Semua credential database PT Nusantara Fintech tidak pernah statis. Vault membuka koneksi administratif ke PostgreSQL dan mengeluarkan kredensial on-demand untuk tiap aplikasi (episode 5):

vault secrets enable -path=database database
 
vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="backend-role,reporting-role" \
  connection_url="postgresql://{{username}}:{{password}}@postgres.internal:5432/nusantara?sslmode=verify-full" \
  username="vault_admin" \
  password="$(cat /etc/vault.d/db-admin-pass)" \
  verify_connection=true
 
vault write database/roles/backend-role \
  db_name=postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

Setiap kali aplikasi (lewat sidecar Agent) membaca database/creds/backend-role, Vault membuat user PostgreSQL baru secara real-time dengan TTL 1 jam, lengkap dengan VALID UNTIL yang memastikan user tersebut mati sendiri di level database meskipun Vault mati. Tidak ada lagi password permanen yang dirotasi manual — rotasi adalah sesuatu yang otomatis terjadi setiap jam.

#Layer 4: Application Security — Transit untuk Enkripsi PII

Data sensitif pelanggan — NIK, nomor kartu kredit — tidak boleh disimpan dalam bentuk plaintext di database aplikasi. Dengan Transit engine (episode 6), PT Nusantara Fintech mengenkripsi PII di dalam aplikasi sementara key-nya dikelola terpusat oleh Vault. Data tetap di aplikasi; hanya key yang di Vault.

vault secrets enable -path=transit transit
 
vault write -f transit/keys/pii-key \
  type=aes256-gcm96 \
  auto_rotate_period="720h"

Backend memanggil Vault untuk enkripsi dan dekripsi:

PLAINTEXT_B64=$(printf '%s' "1234-5678-9012-3456" | base64)
 
vault write transit/encrypt/pii-key \
  plaintext="$PLAINTEXT_B64"

Key            Value
---            -----
ciphertext     vault:v1:abc123...xyz

vault write transit/decrypt/pii-key \
  ciphertext="vault:v1:abc123...xyz"

Saat keamanan menuntut, key dirotasi tanpa mengubah aplikasi:

vault write -f transit/keys/pii-key/rotate

Nilai ciphertext lama tetap bisa didekripsi (versioned key), dan data baru otomatis dienkripsi dengan versi terbaru. Rotasi menjadi operasi satu perintah, bukan migrasi data. Inilah perbedaan utama EaaS vs enkripsi aplikasi tradisional yang kita bahas di episode 6: kunci tidak pernah hidup di kode aplikasi.

#Layer 5: Human Access & Governance — OIDC, Audit, dan Snapshot

Akses manusia ke Vault — engineer, admin, auditor — tidak boleh lewat token statis. Mereka login lewat OIDC dengan identity provider perusahaan (Okta / Azure AD), sehingga akses mengikuti status kepegawaian: karyawan yang keluar dari perusahaan otomatis kehilangan akses (episode 10 & 11).

vault auth enable oidc
 
vault write auth/oidc/config \
  oidc_discovery_url="https://nusantara.okta.com" \
  oidc_client_id="VAULT_CLIENT_ID" \
  oidc_client_secret="REDACTED" \
  default_role="engineer"
 
vault write auth/oidc/role/engineer \
  allowed_redirect_uris="https://vault.nusantara.internal/ui/vault/auth/oidc/oidc/callback" \
  user_claim="email" \
  groups_claim="groups" \
  policies="default"

Identitas yang login — dengan policy default plus group-based policy dari Okta — membentuk Entity dengan alias OIDC (episode 11). Grup Okta (mis. platform-team, data-team) dipetakan ke policy internal Vault, sehingga governance mengalir dari satu sumber: manajemen identitas perusahaan.

Semua akses dicatat oleh audit device (episode 22) dan dikirim ke Grafana Loki untuk query dan alerting:

vault audit enable file file_path=/var/log/vault/audit.log log_raw=false

scrape_configs:
  - job_name: vault-audit
    static_configs:
      - targets:
          - localhost
        labels:
          job: vault-audit
          __path__: /var/log/vault/audit.log

Terakhir, snapshot Raft harian menjamin pemulihan saat bencana (episode 22), dikirim ke bucket S3 terpisah di region lain:

0 2 * * * vault /usr/local/bin/scripts/vault-snapshot-daily.sh
 
# Isi script: vault operator raft snapshot save -> aws s3 cp (bucket terpisah, KMS-encrypted)

#Checklist Kesiapan Produksi Vault

Sebelum arsitektur kalian layak disebut production-grade, lewati seluruh checklist berikut — hasil sintesis seluruh seri:

#Rekap Perjalanan: Dari Episode 0 ke Episode 25

Mari kita lihat peta besar yang sudah kalian lalui bersama selama dua puluh enam episode:

Dari sekadar menjalankan vault server -dev di episode 0, kalian kini mampu merancang sistem di mana seluruh secret perusahaan dikelola oleh satu platform yang tersedia, terukur, teraudit, dan bisa dipulihkan. Itu adalah kemampuan langka yang bernilai sangat tinggi di pasar kerja security, DevOps, SRE, dan cloud engineering.

#Penutup

Selamat — kalian telah menyelesaikan seri Belajar Secret Management dengan HashiCorp Vault dari episode 0 hingga episode 25!

Di episode pamungkas ini kita telah merangkai arsitektur enterprise end-to-end untuk PT Nusantara Fintech: infrastructure layer (cluster 3-node Raft + AWS KMS auto-unseal + TLS), Kubernetes integration (Agent Sidecar Injector + K8s auth di EKS), database security (dynamic PostgreSQL credentials TTL 1 jam), application security (Transit untuk enkripsi PII), dan human access & governance (OIDC via Okta, audit ke Grafana Loki, snapshot harian). Kita menutupnya dengan checklist kesiapan produksi yang menjadikan seluruh pelajaran seri ini sebagai satu gerbang menuju production.

Namun yang paling berharga bukanlah konfigurasinya — melainkan cara berpikir yang sekarang kalian miliki:

1. Secret tidak boleh hidup di kode — semua rahasia terpusat, versi, dan teraudit. (episode 1)
2. Kredensial harus berumur pendek — dynamic secrets mengubah "kebocoran" dari bencana menjadi insiden kecil. (episode 5)
3. Key dipisah dari data — Transit memberi enkripsi tanpa memindahkan key ke aplikasi. (episode 6)
4. Akses berbasis identitas, bukan kata sandi — OIDC, Kubernetes auth, AppRole; manusia dan mesin terautentikasi dengan jelas. (episode 10)
5. Segala sesuatu harus terversi dan ter-audit — leases, policies, audit log, semuanya bisa ditelusuri. (episode 9, 12, 22)
6. Sistem harus tersedia dan bisa pulih — HA, auto-unseal, snapshot, dan runbook yang terlatih. (episode 20, 21, 22)
7. Bisa diamati — jika tidak terukur, tidak bisa dikelola. (episode 24)

Perjalanan kalian tidak berhenti di sini. Beberapa langkah berikutnya yang bisa kalian ambil untuk terus tumbuh:

• Bangun project sungguhan — ambil satu workload (misal API kecil), deploy dengan arsitektur di episode ini, dan latih seluruh checklist produksinya. Failure drill, rotate key, cabut lease, pulihkan snapshot — lakukan semuanya.
• Eksplorasi ekosistem pelengkap — dalami integrasi Vault Secrets Operator (episode 17) untuk sinkronisasi secret native Kubernetes, pelajari Vault Enterprise (Namespaces, Replication, Sentinel) jika organisasi membutuhkannya, atau bandingkan dengan OpenBao untuk kebutuhan open source penuh.
• Perdalam keamanan berlapis — gabungkan dengan konsep zero-trust, SPIFFE/SPIRE untuk workload identity, dan audit/GRC yang lebih formal (PCI-DSS, SOC 2).
• Kontribusi dan berbagi — tulis policy Vault, modul Terraform untuk deployment Vault, atau bagikan pengalaman operasional kalian dalam bentuk tulisan. Mengajar adalah cara terbaik untuk benar-benar menguasai.

Ingatlah kalimat dari episode 3: Vault bukan sekadar gudang rahasia — ia adalah sistem kepercayaan untuk seluruh organisasi. Kepercayaan bahwa secret dijaga, akses diawasi, dan recovery dimungkinkan. Engineer yang bisa memberikan kepercayaan itu adalah engineer yang diandalkan organisasi.

Terima kasih sudah menemani perjalanan ini sampai akhir. Sekarang — buka terminal, inisialisasi cluster Vault pertama kalian, dan jadikan secret management sebagai sesuatu yang bisa dipertanggungjawabkan. Selamat berkarya sebagai engineer keamanan dan infrastruktur yang sesungguhnya! 🔐🚀