Add support for cluster-scoped trigger authentication

[coderanger]

This allows creating a single authentication for Keda, for scalers where that makes sense.

ClusterTriggerAuthentication objects work just like TriggerAuthentication but are not in a specific namespace. SecretRefs in them will looked up in the namespace Keda is running in (overridable via $KEDA_CLUSTER_OBJECT_NAMESPACE for special cases). In triggers, you set kind: ClusterTriggerAuthentication.

Overall this is modeled on cert-manager's ClusterIssuer and Issuer types. Holding off on adding documentation since I'm not sure of the best way to document this since it is kind of a big feature.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO)
• Tests have been added
• A PR is opened to update the documentation on https://github.com/kedacore/keda-docs
• Changelog has been updated

Relates to #1469

[tomkerkhove]

WDYT @zroubalik? I think we've explicitly gone with namespace-scoping since that is typically used as a security boundary but I can see value in having a cluster-wide auth mode.

[tomkerkhove]

If we agree on this, please open a doc PR

[tomkerkhove]

Thanks for the PR btw!

[coderanger]

My specific use case is I want to make a single keda RabbitMQ user with access to the HTTP API without also giving all my normal clients that access. And just in general it's nice to have Keda-specific credentials for tracking and auditing, without having to copy those to every application namespace that uses RabbitMQ scaling. This could also be implemented directly into the RabbitMQ scaler but that seemed more hacky.

[tomkerkhove]

Makes perfect sense, thanks!

[tomkerkhove]

See kedacore/keda-docs#340 (comment) where I would move the $KEDA_CLUSTER_OBJECT_NAMESPACE environment variable to the declaration in case they want to change it

[zroubalik]

Thanks for this PR, I can see the need for this feature. I like the way on how this is modelled wrt security (limiting Secrets to only one namespace).
This might be worth discussing on the community call.