Managing Credentials Securely
KEDA needs credentials to query external event sources — an AWS Access Key to call SQS, a connection string to query Azure Service Bus, a Kafka SASL password. Embedding these directly in the ScaledObject manifest would mean storing secrets in plain YAML, which is a security anti-pattern.
KEDA solves this with a dedicated resource: TriggerAuthentication (namespace-scoped) and ClusterTriggerAuthentication (cluster-wide). These resources define how to obtain credentials, and ScaledObject references them by name.
Option 1: Kubernetes Secret Reference
The most common approach. You store credentials in a standard Kubernetes Secret, and the TriggerAuthentication's secretTargetRef maps each secret key to the specific parameter name KEDA's scaler expects — for example, mapping an access-key-id key to the awsAccessKeyID parameter, and a secret-access-key key to awsSecretAccessKey.
Option 2: Pod Identity (Recommended for Cloud Workloads)
The superior approach for cloud-hosted clusters. Instead of static credentials, you use the cloud provider's identity system:
- AWS: IAM Roles for Service Accounts (IRSA) — annotate the service account, and KEDA's pods automatically receive temporary credentials via the AWS metadata service.
- Azure: Workload Identity or AAD Pod Identity — bind an Azure Managed Identity to the pod.
- GCP: Workload Identity — bind a GCP Service Account to the Kubernetes Service Account.
Rather than referencing a Secret, this TriggerAuthentication instead sets a podIdentity.provider field naming the cloud provider (aws, azure, azure-workload, gcp, or none). With this approach, there are no static secrets to rotate, leak, or accidentally commit to Git. The cloud provider handles credential issuance and rotation automatically.
Linking Auth to a ScaledObject
A trigger links to whichever TriggerAuthentication it needs simply by name, via its authenticationRef field — the rest of the trigger's configuration (queue URL, target length, region) stays the same regardless of which authentication method backs it.
If asked "How do you handle secrets in KEDA?", the answer that impresses is: "We prefer pod identity over static secrets — IRSA on AWS, Workload Identity on GCP/Azure. This eliminates the secret rotation problem entirely and follows the principle of least privilege, since the IAM role can be scoped to only the specific queue KEDA needs to read." This shows you think about security posture, not just functionality.