Belajar 9router - Secrets & Integration Security

#Pendahuluan

Di episode 10 kalian membuat perubahan routing bisa di-rollback dengan aman. Tapi ada satu kelas rahasia yang tidak boleh masuk version control sama sekali: credential. Satu API key bocor di commit berarti seluruh gateway bisa disalahgunakan — dan tagihan LLM mengalir ke penyerang.

Episode 11 menutup sisi keamanan fondasi: secrets dan integration security. Kita bahas kenapa credential provider tidak boleh ditaruh mentah di config, cara menyimpan API key dan service token secara terpusat, mereferensikan secret dari config tanpa menuliskannya, integrasi aman dengan toolchain eksternal, serta strategi rotation dan least privilege access.

#Kenapa Credential Bukan Sekadar Env Var

Banyak orang berhenti di "simpan di environment variable". Itu awal yang baik, tapi bukan titik akhir. Env var yang di-hardcode di Dockerfile atau compose file masih merupakan plaintext yang bisa bocor lewat image, logs, atau snapshot container. Credential membutuhkan kelas perlakuan sendiri: terenkripsi saat disimpan, dirotasi rutin, dan diberi hak akses seminimal mungkin.

Ada tiga jenis rahasia yang sering dipegang gateway: API key LLM provider (OpenAI, Anthropic, Azure), service token untuk otentikasi ke toolchain eksternal, dan encryption keys untuk data internal. Ketiganya punya siklus hidup dan risiko berbeda — perlakukan masing-masing sebagai secret mandiri, bukan satu blok rahasia.

Warning

Aturan pertama: secret tidak pernah masuk repo, image, atau log. Kalau satu secret saja bocor, seluruh rantai integrasi yang memakainya ikut terancam — bukan hanya satu provider.

#Menyimpan Secret Secara Terpusat

9router tidak menyimpan credential di file config; ia membaca dari secret manager. Opsi paling sederhana untuk memulai adalah secret manager cloud (AWS Secrets Manager, GCP Secret Manager, atau HashiCorp Vault), lalu referensikan lewat ID, bukan nilai. Ini memisahkan "config apa" dari "rahasia apa".

Mapping secret manager ke provider

secrets:
  backend: vault
  address: https://vault.internal:8200
  providers:
    openai: vault:kv/9router/openai#api_key
    anthropic: vault:kv/9router/anthropic#api_key
    azure: vault:kv/9router/azure#api_key
  service_tokens:
    slack: vault:kv/9router/tools/slack#token

Gateway memuat nilai secret dari Vault saat startup dan menyimpannya hanya di memori, tidak pernah di disk atau config. Setiap akses ke secret bisa diaudit oleh secret manager, sehingga kalian tahu siapa mengambil key apa dan kapan. Pastikan koneksi gateway ke Vault memakai otentikasi sendiri yang lebih kuat dari sekadar token statis.

#Mereferensikan Secret di Config

Config tetap deklaratif dan bersih dari nilai rahasia. Template referensi berbentuk vault:path#field — kalian hanya menyebut lokasi, bukan isi. Saat deploy ke banyak environment, cukup ganti backend atau path, tanpa menyentuh nilai rahasia sama sekali.

Verifikasi resolusi secret

npx @9router/cli secrets check

Hasil pemeriksaan secret

{
  "providers": { "openai": "resolved", "anthropic": "resolved", "azure": "missing" },
  "service_tokens": { "slack": "resolved" },
  "recent_rotation": { "openai": "21 days ago" }
}

Perintah npx @9router/cli secrets check memvalidasi bahwa semua referensi bisa di-resolve tanpa pernah mencetak nilainya. Ini menutup celah klasik: config yang lulus validasi struktur tetapi gagal saat runtime karena path secret salah. Jalankan pemeriksaan ini bersama validasi di CI seperti episode 10.

#Integrasi Aman dengan Toolchain Eksternal

Gateway 9router sering memanggil toolchain eksternal — database, CRM, message broker — menggunakan service token. Integrasi aman berarti tiga hal: token disimpan terpusat, koneksi dienkripsi saat transit, dan hak akses token dibatasi cakupannya. Untuk mTLS atau otentikasi kunci, simpan juga material kunci di secret manager.

Integrasi toolchain dengan scope terbatas

integrations:
  - name: crm
    type: api
    url: https://crm.internal/api
    auth: token
    secret: vault:kv/9router/tools/crm#token
    tls:
      min_version: "1.2"
    allowed_scopes: [crm:read]

Perhatikan allowed_scopes hanya crm:read. Token ini tidak bisa menulis, menghapus, atau mengakses resource lain — kerusakan yang bisa dilakukan bila token bocor ikut terbatas. Selalu enkripsi koneksi dengan TLS dan pastikan tidak ada service token yang lolos ke provider LLM sebagai konteks request.

Info

Prinsip zero trust juga berlaku ke arah sebaliknya: jangan berikan toolchain eksternal akses ke gateway kalian hanya karena gateway memanggil mereka. Setiap integrasi memakai identitas sendiri yang bisa dicabut.

#Rotation Strategy dan Least Privilege

Credential harus berubah secara berkala karena waktu memperbesar kemungkinan bocor. Rotasi yang baik bersifat otomatis dan dua fase: key baru dipakai dulu sebelum key lama dihapus, sehingga tidak ada momen layanan mati. 9router mendukung kredensial berganda per provider agar transisi mulus.

Kredensial berganda untuk rotasi mulus

providers:
  openai:
    credentials:
      - id: active
        secret: vault:kv/9router/openai#key_v2
      - id: previous
        secret: vault:kv/9router/openai#key_v1
        status: draining

Saat key_v1 masuk status draining, gateway memakai key_v2 untuk request baru dan menyelesaikan request lama dengan key_v1 sampai kosong, lalu key_v1 dihapus. Siklus ini juga bisa dipicu dari CLI: 9router secrets rotate --provider openai menukar status active dan previous secara otomatis, sehingga alur drain dan delete berjalan tanpa edit config manual.

Pasangkan dengan least privilege: setiap secret hanya punya scope yang dibutuhkan fungsi spesifiknya — token analitik tidak bisa menulis model, key staging tidak boleh mengakses prod. Jadwalkan rotasi sebagai rutinitas berkala, misalnya tiap 90 hari, dan hubungkan dengan audit secret manager agar tidak ada key yang menganggur tanpa pengingat. Cabut secret yang sudah tidak dipakai — secret lama yang tidak dirotasi dan tidak dihapus adalah waktu tunggu untuk bocor.

#Penutup

Secrets and integration security menyatukan semua yang kalian pelajari: credential dikeluarkan dari config dan disimpan terpusat, config hanya memegang referensi, toolchain eksternal diakses dengan token berscope terbatas lewat koneksi terenkripsi, dan rotasi dua fase menjaga layanan tetap hidup sambil membersihkan key lama. Least privilege menjadi filter terakhir — setiap rahasia hanya boleh melakukan yang memang tugasnya.

Inti yang harus dibawa pulang:

Credential tidak pernah masuk repo, image, config, atau log — simpan di secret manager.
Config hanya memegang referensi seperti vault:path#field, bukan nilai rahasia.
Pemeriksaan resolusi secret di CI menangkap referensi rusak sebelum produksi.
Integrasi eksternal memakai token berscope minimal dan koneksi TLS.
Rotasi dua fase dengan status draining memungkinkan pergantian key tanpa downtime.

Episode 12 membuka Fase 4 keamanan yang lebih luas: Secure Gateway & Access Control — otentikasi request masuk, otorisasi akses route dan tool invocation, hingga transport security dan koneksi provider terenkripsi. Sampai jumpa!