Support bound service account tokens

[maxcao13]

Proposal

Currently, there exists the normal Secret Auth Provider which you can use to reference an embedded token for your scaler. Since Kubernetes 1.22, there is the Bound service account token feature that allows short-lived tokens to be mounted as projectedVolumes to your pods vs. long lived explicit tokens that you manually embed in a Secret.

I propose that Keda should support bound service account tokens as a new AuthenticationProvider (maybe called BoundServiceAccountToken or something).

I'm not exactly sure how this would be implemented but I was thinking that users would reference a ServiceAccount to create the token from, Keda calls the k8s TokenRequest API, and embeds that short-lived token in its own Secret. We would like to eliminate secrets completely here, but I'm not sure how we would store the state of an existing token otherwise. Very open to discussions and suggestions.

Use-Case

This would remove the extra step of the user explicitly creating a secret for a long-lived service account token and move away from legacy long-lived API tokens towards the k8s recommended TokenRequest API instead.

Here's a proof of concept of what I was thinking:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: bound-trigger
  namespace: myproject
spec:
  boundServiceAccountToken:
    - parameter: token
      serviceAccountName: mysa
      secretName: boundsecret
      expiry: 1h

parameter: identical to Secret and ConfigMap auth provider serviceAccountName: name of the serviceAccount you want to generate the token from secretName: name of a secret you want to store the short lived token in expiry: when the token expires

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

The docs show the old way that you can reference a long-lived token (which involves creating your own secret) https://keda.sh/docs/2.15/scalers/metrics-api/#example