Belajar Vault - Integrasi Vault dengan Kubernetes (K8s Auth & Agent Injector)

#Pendahuluan

Setelah di episode 16 sebelumnya kita membahas integrasi langsung aplikasi ke Vault lewat SDK — lengkap dengan pola retry, renewal, dan fallback — pada episode kali ini kita akan membahas integrasi yang paling banyak dipakai di dunia cloud-native: Vault dengan Kubernetes.

Mengapa topik ini penting? Hampir semua perusahaan yang memakai Vault di produksi menjalankan aplikasinya di Kubernetes. Masalahnya: cara tradisional memberikan secret ke Pod — yaitu menulis nilai rahasia langsung ke Secret Kubernetes — masih menyimpan secret dalam bentuk statis di etcd, mudah terbaca siapa saja yang punya akses, dan tidak pernah terotentikasi ke Vault. Di episode ini kita akan menyelesaikan masalah tersebut dengan tiga mekanisme utama: Kubernetes Auth Method untuk otentikasi, Vault Agent Sidecar Injector untuk injeksi secret otomatis ke Pod, dan Vault Secrets Operator (VSO) untuk sinkronisasi secret ke native Kubernetes Secret. Mari kita bedah satu per satu.

#Pembahasan Utama

#Kubernetes Auth Method (auth/kubernetes)

Kubernetes Auth Method adalah cara Pod berotentikasi ke Vault tanpa perlu menyimpan token atau secret ID. Konsepnya: setiap Pod di Kubernetes otomatis memiliki ServiceAccount dan setiap ServiceAccount memiliki JWT token yang melekat. JWT inilah yang menjadi "bukti identitas" Pod ke Vault.

Alur autentikasinya seperti ini:

Pod (SA: web-sa)
   │  1. kirim ServiceAccount JWT ke Vault: auth/kubernetes/login
   ▼
Vault  ──2. verify JWT──▶ Kubernetes API (TokenReview)
   ▲                          │ 3. valid / invalid + claims SA & namespace
   └──4. issue Vault token ───┘

Vault tidak menebak-nebak apakah JWT itu asli — ia meminta Kubernetes API Server untuk memverifikasi token lewat endpoint TokenReview. Dengan begitu, Vault percaya penuh bahwa token tersebut memang milik ServiceAccount tertentu di namespace tertentu.

#Mengaktifkan & Mengonfigurasi K8s Auth

Langkah pertama mengaktifkan auth method dan menghubungkannya ke cluster. Vault membutuhkan tiga hal: alamat Kubernetes API, CA certificate cluster, dan JWT dari service account yang berhak melakukan TokenReview:

vault auth enable kubernetes
 
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc" \
  token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

#Membuat Role yang Terikat ServiceAccount

Setelah konfigurasi, kita buat role yang mengikat ServiceAccount tertentu dengan policy Vault. Ini adalah titik kontrol akses yang krusial: hanya Pod dengan SA bernama web-sa di namespace default yang boleh login lewat role web:

vault write auth/kubernetes/role/web \
  bound_service_account_names="web-sa" \
  bound_service_account_namespaces="default" \
  policies="web-app" \
  ttl="1h"

Perhatikan juga policy Vault yang dilekatkan ke role tersebut harus mengizinkan akses ke path yang dibutuhkan aplikasi:

path "secret/data/myapp" {
  capabilities = ["read"]
}

#Vault Agent Sidecar Injector

Kubernetes Auth Method sudah membuat Pod bisa berotentikasi, tapi kita masih perlu cara men-deliver secret ke dalam Pod. Di sinilah Vault Agent Sidecar Injector berperan: sebuah mutating admission webhook yang otomatis menambahkan container sidecar Vault Agent ke dalam Pod berdasarkan annotations.

Cara kerjanya:

1. Kalian menulis Deployment biasa dengan annotations vault.hashicorp.com/....
2. Saat Pod dibuat, webhook injector menambahkan sidecar container vault-agent dan volume memori /vault/secrets.
3. Sidecar melakukan auto-auth via Kubernetes Auth Method, membaca secret dari Vault, lalu merender file ke /vault/secrets/config.
4. Aplikasi membaca file tersebut — tanpa perlu tahu Vault sama sekali.

#Menyiapkan Service Account & Menginstal Injector

Sebelum deployment berjalan, ada dua persiapan wajib. Pertama, buat ServiceAccount web-sa — identitas yang akan membuktikan diri ke Vault:

service-account.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-sa
  namespace: default

Kedua, pasang Vault Agent Injector di cluster. Cara paling umum adalah via Helm chart hashicorp/vault dengan sub-chart injector (atau install mandiri chart injector):

Install Vault Agent Injector via Helm

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault \
  --set injector.enabled=true \
  --set injector.logLevel=info

Verifikasi webhook injector aktif

kubectl get mutatingwebhookconfiguration
kubectl get pods -n vault

#Deployment dengan Annotations Injector

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "web"
        vault.hashicorp.com/agent-inject-secret-config: "secret/data/myapp"
        vault.hashicorp.com/agent-inject-template-config: |
          {{- with secret "secret/data/myapp" }}
          DB_HOST={{ .Data.data.DB_HOST }}
          DB_PASSWORD={{ .Data.data.DB_PASSWORD }}
          {{- end }}
    spec:
      serviceAccountName: web-sa
      containers:
        - name: myapp
          image: myapp:1.0.0
          command: ["sh", "-c", "sleep infinity"]

Penjelasan annotation kunci:

• vault.hashicorp.com/agent-inject: "true" — penanda bahwa injector harus memproses Pod ini.
• vault.hashicorp.com/role: "web" — role K8s auth yang dipakai sidecar untuk login (harus match dengan bound_service_account_names).
• vault.hashicorp.com/agent-inject-secret-config — nama file tujuan (config) dipisahkan dari path secret (secret/data/myapp) oleh -. Hasilnya secret di-render ke /vault/secrets/config.
• agent-inject-template-config — template custom yang mengontrol isi file. Tanpa template ini, injector memakai template bawaan (format YAML) yang sering kurang sesuai kebutuhan.

#Hasil Render di Dalam Pod

Setelah Pod berjalan, mari kita lihat apa yang dihasilkan sidecar:

Cek file secret di dalam Pod

kubectl exec deploy/myapp -- cat /vault/secrets/config

DB_HOST=postgres.internal.local
DB_PASSWORD=a9f3!sVx#2kQ

#Apa yang Terjadi saat Secret di Vault Dirotasi?

Ini keunggulan utama injector: jika secret di Vault diubah, sidecar agent mendeteksi perubahannya (via polling ke Vault) dan merender ulang file secara otomatis. Aplikasi yang membaca file setiap kali membutuhkan koneksi akan otomatis memakai nilai terbaru. Tapi perhatikan — aplikasi yang sudah menyimpan nilai lama di memori (misal koneksi pool yang dibangun saat startup) tidak akan terpengaruh sampai ia membaca ulang file atau di-restart. Untuk aplikasi yang perlu merespons rotasi cepat, tambahkan reloader seperti restart otomatis saat file berubah.

#Vault Secrets Operator (VSO)

Sidecar injector menyelesaikan masalah injection, tapi ada kasus lain: aplikasi (atau tooling seperti Helm chart, ingress, dsb.) memang membutuhkan native Kubernetes Secret — bukan file di dalam Pod. Di sinilah Vault Secrets Operator (VSO) masuk: operator ini menyinkronkan secret dari Vault ke native Secret Kubernetes secara kontinu, lengkap dengan rotasi otomatis.

Arsitekturnya terdiri dari beberapa CRD (Custom Resource Definition):

• VaultConnection — alamat Vault yang akan dihubungi.
• VaultAuth — kredensial otentikasi (misal via Kubernetes Auth Method).
• VaultStaticSecret — sumber secret dan tujuan sinkronisasi (destination).
• (Ada juga VaultDynamicSecret untuk dynamic credentials, dan VaultPKISecret untuk sertifikat — kita fokus ke static dulu.)

vso.yaml

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
  name: vault
  namespace: default
spec:
  address: http://vault:8200
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: vault-auth
  namespace: default
spec:
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: web
    serviceAccount: web-sa
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: myapp-secret
  namespace: default
spec:
  vaultAuthRef: vault-auth
  mount: secret
  type: kv-v2
  path: myapp
  refreshAfter: 1h
  destination:
    name: myapp-secrets
    create: true
    overwrite: true

Penjelasan bagian penting:

• vaultAuthRef menunjuk ke VaultAuth yang memakai Kubernetes Auth dengan role web dan service account web-sa.
• mount: secret + type: kv-v2 + path: myapp berarti sumbernya adalah secret/data/myapp pada secrets engine KV v2.
• refreshAfter: 1h menentukan interval sinkronisasi — setiap jam operator membandingkan versi secret di Vault dan memperbarui Secret Kubernetes jika ada perubahan.
• destination mendefinisikan Secret bernama myapp-secrets yang akan dibuat/diperbarui.

VSO juga mendukung dynamic credentials lewat CRD VaultDynamicSecret. Contohnya, mengambil kredensial database sementara dari secrets engine database dan menyinkronkannya ke Secret:

vso-dynamic.yaml

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultDynamicSecret
metadata:
  name: db-creds
  namespace: default
spec:
  vaultAuthRef: vault-auth
  mount: database
  role: web-role
  destination:
    name: db-creds
    create: true
  revoke: true
  renewalPercent: 60

Hasilnya, sebuah Secret native Kubernetes siap dipakai aplikasi:

Secret native hasil sinkronisasi

kubectl get secret myapp-secrets -o jsonpath='{.data}'

{
  "DB_HOST": "cG9zdGdyZXMuaW50ZXJuYWwubG9jYWw=",
  "DB_PASSWORD": "YTlmMyFzVngjMmtR"
}

#Sidecar Injector vs VSO: Kapan Pakai yang Mana?

#Kesalahan Umum Integrasi Vault-Kubernetes

#Penutup

Pada episode 17 ini kita telah membahas integrasi Vault dengan Kubernetes secara menyeluruh: Kubernetes Auth Method yang memverifikasi ServiceAccount JWT melalui TokenReview API, Vault Agent Sidecar Injector yang otomatis menyuntikkan sidecar untuk merender secret ke /vault/secrets/config di dalam RAM, dan Vault Secrets Operator (VSO) yang menyinkronkan secret ke native Kubernetes Secret dengan rotasi otomatis.

Inti pelajaran episode ini: identitas Pod di Kubernetes (ServiceAccount) adalah kunci otentikasi yang kuat ke Vault — tidak perlu lagi menyimpan token di mana pun. Pilih injector ketika kalian ingin secret berakhir di memori Pod, pilih VSO ketika tooling kalian membutuhkan objek Secret native.

Di episode 18 selanjutnya kita akan berpindah ke dunia otomasi pengembangan: integrasi Vault di CI/CD pipeline (GitHub Actions & GitLab CI) — bagaimana pipeline mengambil kredensial sementara dari Vault tanpa menyimpan secret statis di repository. Pastikan tetap semangat!