Learn KEDA - TriggerAuthentication

#Introduction

After episodes 4 and 5, you can create working ScaledObjects and ScaledJobs. But there's one practical hurdle waiting the moment a scaler touches a real system: authentication. A protected SQS queue, Kafka, or Prometheus won't hand over data just because you ask for it.

Episode 6 covers TriggerAuthentication and ClusterTriggerAuthentication: objects that store how KEDA proves its identity to event sources, complete with the most common credential patterns in the field.

#Why a Separate Object?

Credentials are highly sensitive data. You don't want to write them inside a ScaledObject — an object managed by many people and often committed to Git. KEDA separates the two: the ScaledObject holds "what to read", the TriggerAuthentication holds "with what credentials to read it".

ScaledObject referencing authentication

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"

Credentials are defined separately, replaced by a reference to the authentication object's name. Credential rotation never touches the ScaledObject at all. To see how this authentication object is referenced from KEDA's side, run kubectl get triggerauthentication -n your-namespace and read its spec field.

#Authentication Patterns

KEDA provides three main patterns. Choose based on your infrastructure and the level of security you need.

#secretTargetRef: Credentials from a Secret

The simplest pattern: credentials are stored in a Kubernetes Secret, then read by KEDA and passed as scaler parameters.

TriggerAuthentication with 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

The parameter field connects a value to the parameter the scaler expects, while name and key point at the Secret. Make sure the Secret is in the same namespace — this pattern can't cross namespaces.

#env: Credentials from the Environment

The env pattern takes credentials from the KEDA pod's environment variables — useful when credentials are injected by an external mechanism, such as an init container or admission controller:

TriggerAuthentication with env

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

The PROMETHEUS_TOKEN value is read from the keda-operator environment at runtime, not from a YAML file — credentials never appear in Git.

#podIdentity: Cloud Workload Identity

The safest and most modern pattern: no static credentials at all. KEDA uses the cloud workload identity already attached to the operator pod — an IAM role on AWS, a managed identity on Azure, or a service account on GCP.

TriggerAuthentication with AWS IRSA podIdentity

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

Available providers: aws (IRSA/EKS), azure (Azure workload identity for AKS), and gcp (GCP IAM Workload Identity). The key to this pattern: the KEDA operator is annotated with an identity that has minimal permissions — for example, only sqs:GetQueueAttributes to read queue length. No rotating secrets, no credential leaks.

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

#TriggerAuthentication vs ClusterTriggerAuthentication

The difference between the two is as simple as scope:

With ClusterTriggerAuthentication, a platform team can provide credentials to the company queue once, and then all teams in all namespaces use it — without each team storing its own secret:

Using 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"

#Vault and External Secret Integration

For organizations already using HashiCorp Vault or external operators (External Secrets Operator, Sealed Secrets), the favorite pattern is populating Kubernetes Secrets from Vault, then using the secretTargetRef pattern. KEDA doesn't need to know Vault exists:

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

Credential rotation is handled by the External Secrets Operator in one place, and the TriggerAuthentication stays stable. This pattern combines Vault security with the simplicity of secretTargetRef.

#Conclusion

Episode 6 closes the access security foundation. Here's what you must bring along:

• TriggerAuthentication separates credentials from the ScaledObject.
• Three patterns: secretTargetRef, env, and podIdentity (safest in the cloud).
• podIdentity supports IRSA/EKS, Azure workload identity, and GCP IAM.
• ClusterTriggerAuthentication for centralized cross-namespace credentials.
• Combine with Vault/External Secrets for centralized rotation.

In episode 7 we'll get to know the scalers most often used for everyday workloads: CPU/memory and cron for schedule prediction, then Prometheus and HTTP for custom metrics and pending requests.