Belajar KEDA - Security & Credentials

#Pendahuluan

Di episode 12 kita menuntaskan HTTP Add-on. Tapi ada satu hal yang selama ini kita pakai tanpa membahas serius: kredensial. Semua scaler — SQS, RabbitMQ, Prometheus, database — butuh akses ke sistem eksternal, dan mengelola akses itu dengan benar adalah perbedaan antara autoscaling yang aman dan kebocoran data. Di episode ini kita membahas best practice secret management, podIdentity di tiga cloud, integrasi HashiCorp Vault, rotasi, dan prinsip least privilege.

#Prinsip: Kredensial Tidak Pernah di Manifest

Aturan emas keamanan KEDA: ScaledObject tidak pernah memuat kredensial. Semua rahasia disimpan di Kubernetes Secret, lalu diacu lewat TriggerAuthentication (namespace-scoped) atau ClusterTriggerAuthentication (cluster-wide). Kredensial yang ditulis langsung di metadata ScaledObject akan tersimpan polos di etcd dan bisa dibaca siapa pun yang punya akses baca.

#TriggerAuthentication: Secret dan Env

Cara paling sederhana adalah memetakan key di Secret ke parameter scaler.

TriggerAuthentication dengan secretTargetRef

apiVersion: v1
kind: Secret
metadata:
  name: rabbitmq-secret
stringData:
  host: amqp://user:password@rabbitmq.prod.svc:5672
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-auth
spec:
  secretTargetRef:
    - parameter: host
      name: rabbitmq-secret
      key: host

secretTargetRef memetakan key di Secret ke parameter scaler. Jangan pernah menulis rahasia sebagai literal di file yang masuk ke Git — gunakan External Secrets, sealed secret, atau injeksi dari platform. Inventarisasi auth yang dipakai dengan kubectl get triggerauthentication -n production.

#podIdentity: IRSA, Azure AD, dan GCP IAM

Ketiga cloud provider mendukung federasi identitas: pod memakai identitas yang diberikan control plane, tanpa secret statis yang harus dirotasi manual. KEDA cukup menunjuk provider pada TriggerAuthentication.

#AWS: IAM Roles for Service Accounts (IRSA)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: keda-operator
  namespace: keda
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/keda-sqs-role

Annotation role-arn dipasang di ServiceAccount operator KEDA. Role itu hanya boleh berisi izin yang dibutuhkan — misalnya sqs:GetQueueAttributes untuk trigger SQS.

#Azure: Workload Identity

TriggerAuthentication Azure Workload Identity

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-auth
spec:
  podIdentity:
    provider: azure-workload
    identityId: "12345678-1234-1234-1234-123456789012"

KEDA operator dipasangi Azure AD Workload Identity dengan clientId, tenantId, dan federatedIdentityCredentials yang mengikat ServiceAccount ke managed identity.

#GCP: Workload Identity

TriggerAuthentication GCP Workload Identity

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: gcp-auth
spec:
  podIdentity:
    provider: gcp

#Integrasi HashiCorp Vault

Untuk lingkungan yang sudah memakai Vault, KEDA punya authentication provider bawaan. Kredensial diambil dari Vault saat trigger dievaluasi, bukan disalin ke etcd.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: vault-auth
spec:
  secretTargetRef:
    - parameter: host
      name: keda-secrets
      key: host
  vault:
    address: http://vault.vault.svc:8200
    authentication: kubernetes
    kubernetes:
      role: keda-role
      mount: kubernetes
    secrets:
      - parameter: host
        key: rabbitmq
        path: secret/data/keda/rabbitmq

Metode authentication: kubernetes membuat KEDA login ke Vault lewat ServiceAccount-nya. Rotasi cukup dilakukan di Vault tanpa rollout ulang.

#Least Privilege untuk Queue dan Stream

Prinsip paling penting: izin sesempit mungkin. Operator KEDA hanya butuh membaca metrik — bukan menulis atau menghapus pesan.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["sqs:GetQueueAttributes", "sqs:ListQueues"],
      "Resource": "arn:aws:sqs:ap-southeast-3:123456789012:orders"
    }
  ]
}

Untuk Kafka, beri role konsumen hanya operasi baca (DescribeGroup, DescribeTopic, Fetch) pada topic dan group yang spesifik — jangan wildcard. Untuk Redis dan NATS, buat user dengan izin baca saja. Batasi juga RBAC: siapa pun yang bisa membaca Secret bisa membaca kredensialnya.

#Penutup

• Kredensial tidak pernah di manifest; selalu lewat Secret + TriggerAuthentication.
• podIdentity menghilangkan secret statis: IRSA di AWS, Azure AD Workload Identity, GCP IAM.
• Vault terintegrasi native untuk lingkungan on-prem atau legacy, dengan rotasi otomatis.
• Least privilege: IAM per queue, per topic, per stream — baca saja, bukan menulis.
• Pantau keda_scaler_errors_total dan batasi RBAC pembaca Secret.

Kredensial sekarang aman, workload stabil, dan autoscaling berjalan. Tapi kalian bekerja di cluster bersama banyak tim — bagaimana cara mengisolasinya? Di episode 14 kita membahas Multi-Tenancy & RBAC: ClusterTriggerAuthentication, pembatasan scaler per namespace, admission webhooks, dan policy OPA/Gatekeeper untuk mengontrol pemakaian KEDA. Sampai jumpa!