Belajar KEDA - TriggerAuthentication

#Pendahuluan

Setelah episode 4 dan 5, kalian sudah bisa membuat ScaledObject dan ScaledJob yang berfungsi. Tapi ada satu rintangan praktis yang menanti begitu scaler menyentuh sistem sungguhan: autentikasi. Queue SQS, Kafka, atau Prometheus yang diproteksi tidak akan memberi data hanya karena kalian memintanya.

Episode 6 membahas TriggerAuthentication dan ClusterTriggerAuthentication: objek yang menyimpan cara KEDA membuktikan identitasnya ke sumber event, lengkap dengan pola kredensial yang paling umum di lapangan.

#Mengapa Butuh Objek Terpisah?

Kredensial adalah data yang sangat sensitif. Kalian tidak ingin menuliskannya di dalam ScaledObject — objek yang dikelola banyak orang dan sering masuk Git. KEDA memisahkan keduanya: ScaledObject berisi "apa yang dibaca", TriggerAuthentication berisi "dengan kredensial apa membacanya".

ScaledObject mereferensikan autentikasi

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-worker-scaledobject
spec:
  scaleTargetRef:
    name: sqs-worker
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: keda-trigger-auth-sqs
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/1234/orders
        queueLength: "5"

Kredensial didefinisikan terpisah, diganti dengan merujuk nama objek autentikasi. Rotasi kredensial tidak menyentuh ScaledObject sama sekali. Untuk melihat bagaimana objek autentikasi ini dirujuk dari sisi KEDA, jalankan kubectl get triggerauthentication -n your-namespace dan baca field spec-nya.

#Pola Autentikasi

Ada tiga pola utama yang disediakan KEDA. Pilih berdasarkan infrastruktur dan tingkat keamanan yang kalian butuhkan.

#secretTargetRef: Kredensial dari Secret

Pola paling sederhana: kredensial disimpan di Kubernetes Secret, lalu dibaca oleh KEDA dan diteruskan sebagai parameter scaler.

TriggerAuthentication dengan secretTargetRef

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-sqs
spec:
  secretTargetRef:
    - parameter: awsAccessKeyID
      name: aws-secrets
      key: AWS_ACCESS_KEY_ID
    - parameter: awsSecretAccessKey
      name: aws-secrets
      key: AWS_SECRET_ACCESS_KEY

Field parameter menghubungkan nilai ke parameter yang diminta scaler, sementara name dan key menunjuk Secret. Pastikan Secret berada di namespace yang sama — pola ini tidak bisa menyeberang namespace.

#env: Kredensial dari Environment

Pola env mengambil kredensial dari variabel environment pod KEDA — berguna saat kredensial disuntikkan oleh mekanisme luar, misalnya init container atau admission controller:

TriggerAuthentication dengan env

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
spec:
  env:
    - name: PROMETHEUS_TOKEN
      parameter: bearerToken

Nilai PROMETHEUS_TOKEN dibaca dari environment keda-operator saat runtime, bukan dari file YAML — kredensial tidak pernah muncul di Git.

#podIdentity: Identitas Workload Cloud

Pola paling aman dan paling modern: tanpa kredensial statis sama sekali. KEDA memakai identitas workload cloud yang sudah melekat pada pod operator — IAM role di AWS, managed identity di Azure, atau service account di GCP.

TriggerAuthentication dengan podIdentity AWS IRSA

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-aws
spec:
  podIdentity:
    provider: aws
    identityId: arn:aws:iam::123456789012:role/keda-sqs-reader

Provider yang tersedia: aws (IRSA/EKS), azure (Azure workload identity untuk AKS), dan gcp (GCP IAM Workload Identity). Kunci dari pola ini: operator KEDA diannotasi dengan identity yang punya izin minimal — misalnya hanya sqs:GetQueueAttributes untuk membaca panjang queue. Tidak ada secret yang berputar, tidak ada kebocoran kredensial.

kubectl describe scaledobject sqs-worker-scaledobject
kubectl get triggerauthentication
kubectl logs -n keda deploy/keda-operator | tail -20

#TriggerAuthentication vs ClusterTriggerAuthentication

Perbedaan keduanya sesederhana lingkup:

Dengan ClusterTriggerAuthentication, sebuah tim platform bisa menyediakan kredensial ke queue perusahaan sekali, lalu semua tim di semua namespace memakainya — tanpa masing-masing tim menyimpan secret sendiri:

Memakai ClusterTriggerAuthentication

spec:
  triggers:
    - type: aws-sqs-queue
      clusterTriggerAuthenticationRef:
        name: keda-platform-sqs
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/1234/orders
        queueLength: "5"

#Integrasi Vault dan External Secret

Untuk organisasi yang sudah memakai HashiCorp Vault atau operator eksternal (External Secrets Operator, Sealed Secrets), pola favorit adalah mengisi Secret Kubernetes dari Vault, lalu memakai pola secretTargetRef. KEDA tidak perlu tahu keberadaan Vault:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-kafka
spec:
  secretTargetRef:
    - parameter: sasl
      name: kafka-secret
      key: sasl

Rotasi kredensial dilakukan oleh External Secrets Operator di satu tempat, dan TriggerAuthentication tetap stabil. Pola ini menggabungkan keamanan Vault dengan kesederhanaan secretTargetRef.

#Penutup

Episode 6 menutup fondasi keamanan akses. Berikut yang wajib kalian bawa:

• TriggerAuthentication memisahkan kredensial dari ScaledObject.
• Tiga pola: secretTargetRef, env, dan podIdentity (paling aman di cloud).
• podIdentity mendukung IRSA/EKS, Azure workload identity, dan GCP IAM.
• ClusterTriggerAuthentication untuk kredensial terpusat lintas namespace.
• Kombinasikan dengan Vault/External Secrets untuk rotasi terpusat.

Di episode 7 kita berkenalan dengan scaler-scaler yang paling sering dipakai untuk workload biasa: CPU/memory dan cron untuk prediksi jadwal, lalu Prometheus dan HTTP untuk metrik kustom dan pending requests.