Support secret refs for Hashicorp Vault token auth in TriggerAuthentication

[Kunalbehbud]

This PR adds secret-based token resolution for Hashicorp Vault authentication in TriggerAuthentication while preserving backward compatibility for existing plain-text configurations.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy (not applicable)
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (not applicable)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #6026

Relates to kedacore/keda-docs#1724

What changed

• add spec.hashiCorpVault.credential.tokenFrom.secretKeyRef so Vault token auth can read the token from a Kubernetes Secret
• keep existing spec.hashiCorpVault.credential.token support for backward compatibility, but mark it deprecated via admission warnings and documentation
• resolve tokenFrom.secretKeyRef before constructing the Vault handler for both TriggerAuthentication and ClusterTriggerAuthentication
• fix the Hashicorp Vault token auth path to return a clear error when credentials are missing instead of hitting a nil reference panic
• update CRDs, generated deepcopy code, changelog, unit tests, and Hashicorp Vault e2e manifests/docs

Backward compatibility

• existing plain-text credential.token configurations continue to work
• when both tokenFrom.secretKeyRef and token are set, tokenFrom.secretKeyRef takes precedence
• users receive admission warnings recommending migration away from plain-text Vault tokens

How it was tested

• make generate
• make manifests
• make generate-scalers-schema
• PATH="$(go env GOPATH)/bin:$PATH" make golangci
• make test
• go test -tags e2e ./tests/secret-providers/hashicorp_vault -run TestDoesNotExist

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Kunalbehbud]

Could someone take a look at this when convenient? Main CI is green on my side, and the companion docs update is in kedacore/keda-docs#1724. Happy to make follow-up changes if needed.

[rickbrouwer]

Nice work.

Questions:

In resolveHashicorpVaultCredential you write the resolved token back into vault.Credential.Token. Is triggerAuth here guaranteed to be a deep copy? With the default cache-backed client, mutating shared pointers can race across reconciles for the same TriggerAuthentication. Wouldn't it be cleaner to return the resolved token and pass it explicitly to NewHashicorpVaultHandler, so the spec stays immutable and Credential.Token doesn't double as both user-input and resolved-from-secret?

Further, in the logger.Info("WARNING: ...") in resolveAuthRef fires on every reconcile. Given the admission webhook already warns at apply-time, do we need it on the hot path too? Would an event on the TriggerAuthentication or a deprecation metric work better than a recurring log line?

Nit: should Credential.Token also get a // Deprecated: godoc and a note in the CRD description as well? Something for deprecation for V3 I think.