Support JWT authentication for Metrics API scaler

[turbaszek]

Use-Case

Support JWT authentication for Metrics API scaler.

Reference

#929

[ddmendes]

Hello, I'd like to work on this ticket

[turbaszek]

@aman-bansal is this ticker still open? Don't we support JWT in #1137?

[aman-bansal]

No, #1137 supports basic, apikKey and tls. This hasn't been implemented yet.

[ddmendes]

Thanks, I'll work on it!

[JorTurFer]

Which is the state of this?
If you have abandoned it, I could continue from my side :)

[zroubalik]

@JorTurFer that's great! I think that you can work on that, thanks :)

[JorTurFer]

I'm taking a look to this and I have some doubts :/
Is it not supported yet? I mean, it's already supported the use of API-KEY and the jwt token could be a specific config using it I think:

- type: metrics-api
  metadata:
    targetValue: "7"
    url: "http://api:3232/components/stats"
    valueLocation: 'components.worker.tasks'
    authMode: "apiKey"
    method: "header"
    keyParamName: "Authorization"
-------
    apiKey: "bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEiLCJuYW1lIjoiVGVzdCIsInN1cm5hbWUiOiJVc2VyIiwibmJmIjoxNjI4NjI5OTM3LCJleHAiOjE2MjkyMzQ3MzcsImlhdCI6MTYyODYyOTkzN30.mDLtQdEhK6Zj1kStKSQ_6BoI2cvtnTUBQ44P6Ic4dBY"

I have to try it tomorrow (today I have created the server authorized with jwt to test it) but I think that it will work without any change. Maybe it's more a solution that we can document than a problem which requires changes

WDYT? Maybe am I missing anything?

[JorTurFer]

I have just tried and it works fine
This is the config that I used:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sut-deployment
  labels:
    deploy: workload-sut
spec:
  replicas: 0
  selector:
    matchLabels:
      pod: workload-sut
  template:
    metadata:
      labels:
        pod: workload-sut
    spec:
      containers:
        - name: nginx
          image: 'nginx'
---
apiVersion: v1
kind: Secret
metadata:
  name: keda-metric-api-secret
stringData:
  apiKey: "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyJ9.eyJhdWQiOiJmZTgzMTFkNS0xMTcwLTQwNDEtOWRlNy0wZjU0MzYwYWVhZTUiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNmE0NWU4MTUtZWM5ZS00NTE1LTk2YTQtZmRlN2NkMDRiMzRjL3YyLjAiLCJpYXQiOjE2Mjg2MzgzNTEsIm5iZiI6MTYyODYzODM1MSwiZXhwIjoxNjI4NjQyMjUxLCJhaW8iOiJBVFFBeS84VEFBQUEvSG9uc1poZVZhNmtGWVlVd3lkWGZzNnhMbzkyUnh1djV5Qi9Ick9tSTljUEgzazlUYmdMV2JvbE96QlRISUpPIiwiYXpwIjoiZmU4MzExZDUtMTE3MC00MDQxLTlkZTctMGY1NDM2MGFlYWU1IiwiYXpwYWNyIjoiMCIsIm5hbWUiOiJqd3QiLCJvaWQiOiIwMzRhNjdmNS0yNTgxLTRjOWYtODA4ZS1lMDc1NzlhMTE1MmEiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJqd3RAZGV2cGxhaW4ub25taWNyb3NvZnQuY29tIiwicmgiOiIwLkFWOEFGZWhGYXA3c0ZVV1dwUDNuelFTelROVVJnXzV3RVVGQW5lY1BWRFlLNnVWZkFIUS4iLCJzY3AiOiJSZWFkV3JpdGVBY2Nlc3MiLCJzdWIiOiJ4Zk9jT1dBNFVmSHdfcmIwaktOb0hqZ3d2WllkVG5yTFhNN2tPMWhRY29FIiwidGlkIjoiNmE0NWU4MTUtZWM5ZS00NTE1LTk2YTQtZmRlN2NkMDRiMzRjIiwidXRpIjoiZFc4YmhZeTlaMGVuWFlDS1JQNVdBZyIsInZlciI6IjIuMCJ9.EVB_UEUcRt0sdLjnTgp8oS2AsUT6zWH6B3WNvnt3TEKf-5w7sDFuKo9l9WCqch0_PMzLY2KWSe8K2MoUipf3posBewKvNFxAm4vESznIUHa7Y7NY_LLB_wYhcatYr79W7IkEyLGxMH5L7pKifNRahX4a4X9ujVQX3V1E8dmOohrEqy1gzvLo-H1nFI-7EZ2X6lcMIIr5102wQbQFqO0U3vN6ugBR1NNbZ_S7NbbxqdNT4vusBBcuGipUYVAwjeYWdFerx71oGWp4o8hWdaYK1cFmVxW-jEd1XN1gieizWCVvQd26zQy7cqr30KFWayMgqNV7rNxOXg7NECE92YzP2Q"
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-metric-api-creds
spec:
  secretTargetRef:
    - parameter: apiKey
      name: keda-metric-api-secret
      key: apiKey
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sut-scaledobject
spec:
  scaleTargetRef:
    name: sut-deployment
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
  - type: metrics-api
    metadata:
      targetValue: "7"
      url: "https://jwt.fixedbuffer.com/WeatherForecast"
      valueLocation: 'temperatureC'
      authMode: "apiKey"
      method: "header"
      keyParamName: "Authorization"
    authenticationRef:
      name: keda-metric-api-creds

I think that update the documentation to explain it explicitly could be enough

Note: The Bearer was generated using a dummy user that I have created in my AAD for this test, so don't worry, I know that it's public but it hasn't got permissions for anything. Feel free to use the token if you want to try or get your own token using a Microsoft account in SwaggerUI

[zroubalik]

Hmm, sorry for confusion. @aman-bansal could you please confirm?

[JorTurFer]

np :)
Maybe the original topic is related with implementing the method to get the token (using client credentials flow or something similar) instead of the option to pass it 🤔

[tomkerkhove]

This is more of a user-friendly thingy imo - JWT will always use Authorization header and choosing apiKey authentication while it's JWT instead is fairly confusing imo.

I think a dedicated authMode that uses the fixed Authorization header would be a nice addition.

[JorTurFer]

so it's a more cosmetic change that a real feature gap, right?
I feel that if we have a specific mode, it could be more user-friendly (probably some users don't know that JWT could be a specific case of apiKey). I have asked only to be at same page
I will do it ASAP if you agree

[JorTurFer]

Maybe can this ticket be closed? :P