# TriggerAuthentication (KEDA)

> TriggerAuthentications hold the credential references KEDA triggers poll event sources with: Secret keys, environment variables, or a pod identity provider. ZopNight records only counts of secretTargets and envTargets plus the podIdentity setting, never values. A broken authentication stops scaling silently, stranding a workload at 0 or at its last replica count.

Source: https://zop.dev/integrations/kubernetes/triggerauthentication
Updated: 2026-08-19

---

A KEDA TriggerAuthentication holds the credential references scalers use to poll external event sources. It is the second half of the KEDA pair: a ScaledObject's trigger names an authentication object, and that object says which Secret keys, environment variables, or pod identity to log in with.

## Credentials for scalers, not for pods

The distinction is easy to miss. A pod's own Secret mounts let the application talk to the queue; a TriggerAuthentication lets the KEDA operator talk to the queue on the workload's behalf, before any pod exists, which is the whole point of scaling from zero. That is why deleting an "unused" Secret can break scaling for a workload that never mounts it: the reference lives in the TriggerAuthentication, not the pod spec.

## Counted references, never values

Discovery records the shape and only the shape: how many `secretTargetRef` entries, how many `env` entries, and the `podIdentity` provider when one is set. No credential values are read or stored. This is the same keys-only stance applied to Secrets themselves. Like ScaledObjects, the type is listed through the dynamic client against `keda.sh/v1alpha1`, and clusters without KEDA simply return 0 of them without error.

## The failure mode is silence

When a referenced Secret is rotated away or a pod identity binding breaks, KEDA cannot read the event source, and the visible symptom is not an error page but a workload frozen wherever it last was. Frozen at zero means events pile up unprocessed; frozen at a high replica count means paying for consumers with nothing arriving that they can see. Inventorying TriggerAuthentications next to their ScaledObjects is what makes the dependency auditable before it fails.

```bash
kubectl get triggerauthentication -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,PODIDENTITY:.spec.podIdentity.provider
```

## Pod identity is the cleaner pattern

A `podIdentity` provider (workload identity on the cloud side) replaces stored credentials entirely: KEDA assumes the identity instead of reading a key. Where discovery shows a TriggerAuthentication with secret targets pointing at long-lived cloud keys, that is both a rotation liability and a migration candidate, and the podIdentity field is where the better answer would appear.