TriggerAuthentication (KEDA)
Does ZopNight manage 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.
Rules that fire on TriggerAuthentication (KEDA)
No active rule family targets TriggerAuthentication (KEDA) today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
kubectl get triggerauthentication -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,PODIDENTITY:.spec.podIdentity.providerPod 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.