feat: add BoundServiceAccountToken trigger authentication type

[maxcao13]

Provide a description of what has been changed
Implements a new auth provider which allows users to provide authentication using a Kubernetes service account's credentials without creating an explicit long-lived secret.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
  namespace: ingress-operator
spec:
  boundServiceAccountToken:
  - parameter: bearerToken
    serviceAccountName: thanos 

You could already inject Kubernetes service account tokens in triggerAuth refs before by using the Secret trigger auth type, but instead of manually embedding it in a long-lived secret, you can now directly specify the service account instead, and it will embed the sa token in an annotation in the triggerAuth object, and the keda-operator will autorotate the token if the expiry is at least 50% stale. You can specify which parameter you pull into the trigger with parameter, the serviceAccountName in the same namespace as the TriggerAuth CR, and the expiry as a duration. If you use a ClusterTriggerAuth, note that this works similarly to the Secret trigger auth, and the service account then has to be in the KEDA_CLUSTER_OBJECT_NAMESPACE namespace.

This for example can allow keda to scale a workload based on a prometheus instance that requires kubernetes rbac auth inside the cluster without creating a long-lived secret that can potentially be exposed and unrevokable unless you delete the serviceaccount itself. You must specify the service account name (same namespace as the object), the authentication parameter. The token expiry is hardcoded to 1 hour.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes: #6136

[maxcao13]

I know in the community meeting we concluded on a range for expiry as 1h-6h, but is there a reason why we shouldn't allow people to use lower expiries like 10m?

[joelsmith]

I know in the community meeting we concluded on a range for expiry as 1h-6h, but is there a reason why we shouldn't allow people to use lower expiries like 10m?

IMO, there's not a lot of security gained by having 10m vs 1h, and 1h decreases the frequency of new token requests. I don't feel super strongly about it though. In my opinion, we should either hard-code it to 1h or should default to 1h and make it globally-configurable (like via a command-line flag) so that the cluster admin can make the decision about token lifetime for their cluster.

[maxcao13]

Okay I've hardcoded the expiry to 1 hour. If people have qualms about not being able to configure it, I can include a commit to change that. I think this is ready for further review.

[zroubalik]

should default to 1h and make it globally-configurable (like via a command-line flag) so that the cluster admin can make the decision about token lifetime for their cluster.

I like this, I think it makes sense to make it configurable. I think that env variable (or flag) would be great: https://keda.sh/docs/2.16/operate/cluster/#restrict-secret-access

Also, we should definitely consider e2e test for this: https://github.com/kedacore/keda/tree/main/tests/secret-providers

[maxcao13]

E2e test in 0c9444b and configurable token global expiry in b1c68d8

The e2e test depends on this new image to be merged: kedacore/test-tools#186