Using secret on triggers metadata attribute

[robertmujica]

Wondering if it is possible to use secret's value instead of hardcoded values during triggers definition

so instead of doing this

metadata:
bootstrapServers: localhost:9092
consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics
topic: test-topic
# Optional
lagThreshold: "50"
offsetResetPolicy: latest
authenticationRef:
name: keda-trigger-auth-kafka-credential

we would do something like

• secretRef:
  name: secret-name
  metadata:
  bootstrapServers: BOOTSTRAP_SERVER_FROM_SECRET
  consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics
  topic: TOPIC_FROM_SECRET
  # Optional
  lagThreshold: "50"
  offsetResetPolicy: latest
  authenticationRef:
  name: keda-trigger-auth-kafka-credential

so we don't have to duplicate this value and expose value for security reasons across a repo.

[tomkerkhove]

You can do this by using TriggerAuthentication (https://keda.sh/docs/2.1/concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)

[tomkerkhove]

This is what is supported for Kafka - https://keda.sh/docs/2.1/scalers/apache-kafka/#authentication-parameters

bootstrapServers & topic are not considered to be secrets, which is why it's not supported

[robertmujica]

that is a shame, I do like the feature and how it scale up and down based on lag threshold, but I really don't like the idea of duplicating configuration values across yamls files, I like to keep it DRY, maybe a good candidate for backlog 👍

Thanks for quick reply and kudos on this implementation.

[tomkerkhove]

Well, if you are using Helm charts, you can keep it DRY and just use the same value.
That's how I do it, and probably others as well.

[robertmujica]

no i use kustomize and vault, which is a nice tool for handle configuration and central place for secrets, I'm not expert using Helm but if you have a sample please feel free to share, like to see how you will keep it DRY reusing kafka settings across Deployment and ScaledObject yamls.

[james-maersk]

I also would like this to be an option, I would much prefer to keep the value in vault and reference it as a secret than having to duplicate this in our yaml. This means we need to maintain the value in two places.

It would be ideal if we could supply metadata parameters from a secret or env var instead.

The extract from the Keda documentation is also confusing...

Every parameter you define in TriggerAuthentication definition does not need to be included in the metadata of the trigger for your ScaledObject definition. To reference a TriggerAuthentication from a ScaledObject you add the authenticationRef to the trigger.

This makes me assume that the parameters are not ignored, but that seems to be the opposite case.