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

[JorTurFer]

Hello
I think that it's a good idea as projected volumes is the same approach that workload identity federations use but I don't see the use case as kubernetes tokens have to be verified against kubernetes API. Do your backends support auth-delegation with k8s api?

[maxcao13]

Thanks for your response! To clarify, the use case that spawned this idea was autoscaling an Ingress Controller in OpenShift and in that context, we authenticate with Thanos via service accounts: link for more context. In this case our "backend" does support k8s (openshift) api verified tokens, but we are forced to create a long-lived service account secret.

The proposal is to replace this manual process with something more aligned with short-lived bound service account tokens, and I'm very open to hearing about alternative ideas on how to support this as a first step towards best practices. Is this something that should be worked on, and what do you think?

[JorTurFer]

@zroubalik @wozniakjan

[zroubalik]

Sorry, I missed this issue. I think it sounds reasonable, I am curious to hear if there any potential security issues or something that should concern us in general.

[maxcao13]

Unfortunately the only objects you can bind the tokens to (as of now), are to pods and secrets. Since we are sort of trying to eliminate the use of secrets, and it doesn't make sense to bind to any pods, what if we "bind" generated tokens to a TriggerAuth that implements the boundServiceAccountToken auth instead, and implement a simple version of the token rotation, finalizers, etc. ourselves? And we embed the encoded token as an annotation in the TriggerAuth metadata (or somewhere else).

However, a user who can get/list [Cluster]TriggerAuths will also be able to see the embedded service account tokens, so there might be some extra permissions handling to do there. Instead of exposing the tokens in the TriggerAuth, keeping the tokens to be embedded in Secrets, but doing the renewal process on them, could also work. What do we think?