Memanfaatkan YAML untuk konfigurasi auth, sesi, dan rate limit bisa aman asalkan Anda menerapkan validasi schema yang ketat, rotasi secret terjadwal, dan audit rutin. Artikel ini langsung menjawab bagaimana pendekatan dari "In Defense of YAML" bisa diterjemahkan ke praktik hardening secret YAML di lingkungan backend/DevOps.

Kami akan menyorot langkah-langkah validasi schema, rotasi credential, isolasi sesi, proteksi upload, serta rate limit, lengkap dengan contoh konfigurasi dan alat linting yang membantu menjaga konfigurasi YAML tetap ikuti kebijakan keamanan.

Validasi Schema untuk Secrets dan Authentication

YAML bebas bisa rawan kesalahan ketik atau konfigurasi yang tidak diharapkan. Validasi schema mengikat struktur, tipe, dan batasan nilai sehingga file secrets tidak memuat field nggak valid atau bernilai kosong.

Contoh schema JSON untuk memvalidasi entri auth token:

{
  "type": "object",
  "required": ["auth", "session"],
  "properties": {
    "auth": {
      "type": "object",
      "properties": {
        "provider": {"type": "string"},
        "token": {"type": "string", "minLength": 32},
        "scopes": {"type": "array", "items": {"type": "string"}}
      },
      "required": ["provider", "token"]
    },
    "session": {
      "type": "object",
      "properties": {
        "ttl": {"type": "integer", "minimum": 60},
        "storage": {"type": "string", "enum": ["redis", "database"]}
      },
      "required": ["ttl"]
    }
  }
}

Gunakan linting seperti Spectral atau yamllint + jsonschema untuk menguji file YAML terhadap schema di atas sebelum deployment. Jika menggunakan Kubernetes, kubeval bisa memperluas validasi ke CRD yang memuat secrets.

Tips debugging: jika pipeline CI/CD gagal karena validasi, periksa path schema dan runtime dependency. Jangan hanya mengabaikan error karena kesalahan schema bisa menjadi celah eksfiltrasi kredensial.

Tooling Validasi

  • Spectral: buat aturan custom untuk melarang field seperti auth.secretKey kosong atau mendefinisikan level akses minim.
  • yamale atau jsonschema: cocok untuk schema yang dibaca developer dan digunakan saat build.
  • Open Policy Agent: jika konfigurasi YAML memengaruhi policy, gunakan OPA untuk enforcment pada level deployment.

Rotasi Secret dan Isolasi Sesi

Rotasi secret mengurangi waktu eksposur saat kredensial bocor. Terapkan TTL pada secret, gunakan versi, dan definisikan proses rotasi terotomasi.

# Contoh format YAML untuk secret rotation plan
rotation:
  authTokens:
    ttl: 3600 # detik
    rotationWindow: 300 # detik sebelum kadaluarsa untuk generate baru
    executor: "hashicorp-vault/rotate"
  uploadApi:
    ttl: 86400
    notifyChannel: "sec-app-alerts"

Untuk rotasi terjadwal, gunakan pipeline CI/CD atau scheduler (misal CronJob) yang memanggil API Vault/Secrets Manager untuk men-generate secret baru dan memperbarui YAML secara atomik. Pastikan pipeline memiliki hak terbatas (least privilege).

Isolasi sesi dilakukan dengan memetakan setiap sesi ke entri tersendiri, misalnya menyimpan session ID di Redis dengan namespace yang membatasi akses service tertentu.

Isolasi Sesi Praktis

Gunakan struktur YAML yang memisahkan sesi berdasarkan aplikasi/region:

sessions:
  webapp:
    driver: redis
    namespace: "session:webapp"
    maxConcurrent: 3
  api:
    driver: database
    namespace: "session:api"
    ttl: 900

Implementasi panjatkan akses hanya dari service yang memerlukan namespace tersebut, dan perpaduan filter request agar refreshing sesi tidak mempengaruhi session lain.

Proteksi Upload dan Rate Limit

File upload bisa menjadi vektor eksfiltrasi secret. Dalam YAML, atur konfigurasi upload agar mengaktifkan pemindaian antivirus, batas ukuran, serta validation terhadap MIME type.

uploads:
  maxSizeMb: 5
  permittedMime:
    - application/pdf
    - image/jpeg
  virusScan: true
  storage: "s3"
  metadata:
    encryption: "aes256"

Pastikan pipeline validasi memeriksa nilai maxSizeMb dan permittedMime terhadap policy untuk menghindari bypass. Gunakan fitur mutating webhook atau admission controller untuk memeriksa YAML sebelum apply.

Rate limit penting untuk melindungi endpoint auth. Konfigurasi rate limit di YAML dan jalankan enforcement di padanan proxy seperti Envoy atau NGINX.

rateLimit:
  authEndpoint:
    requestsPerMinute: 120
    burst: 20
  uploadEndpoint:
    requestsPerMinute: 30
    burst: 5
  window: 60

Kenapa ini bekerja? Rate limit berbasis konfigurasi memungkinkan DevOps segera mengubah nilai tanpa recompile service. Pastikan tooling Anda memvalidasi bahwa masing-masing endpoint memiliki nilai positif dan batas burst wajar.

Checklist Audit dan Linting

Untuk menjaga konsistensi, pakai checklist auditing yang rutin dijalankan sebagai bagian dari code review atau pipeline:

  • Apakah setiap secret merujuk ke manager (Vault/Secrets Manager) dan tidak tersimpan plaintext di YAML?
  • Apakah schema validasi menolak field tak dikenal atau null yang berbahaya?
  • Apakah setiap entry auth/sesi memiliki ttl dan batas akses yang jelas?
  • Apakah upload dikunci dengan scanning, size limit, dan metadata enkripsi?
  • Apakah rate limit didokumentasikan dan diverifikasi dengan stress test ringan?

Tool yang bisa dipakai:

  • Checkov atau Datree untuk policy as code serta mendeteksi pola insecure pada YAML.
  • Hadolint dan YAML Lint untuk format yang konsisten.
  • Git hook (pre-commit) menjalankan yamllint + schema validation sebelum push.

Catatan debugging: jika rate limit tidak diterapkan, periksa format YAML dan pastikan controller (seperti Envoy) memuat ulang konfigurasi saat file berubah.

Dengan mengikuti praktik ini, Anda tetap mempertahankan fleksibilitas YAML yang dipuja dalam diskusi "In Defense of YAML" sekaligus memitigasi risiko pada auth, secret, upload, dan rate limit di stack backend/DevOps.