Allow properties from ConfigMap in TriggerAuthentication

[novicr]

Currently TriggerAuthentication allows specifying properties from multiple sources including Secrets and Environment. In some cases information like username is already maintained in ConfigMap's. Would be useful to allow specifying properties defined in ConfigMap when defining TriggerAuthentication

[JorTurFer]

Hello,
In one hand, I'm not 100% sure if we should allow this option because it could produce that users store secrets in cofigMaps (at least now KEDA doesn't allow it).
In the other hand, things like username aren't sensitive so if we read them from TriggerAuthentication, supporting configMaps sounds reasonable.
WDTY @kedacore/keda-core-contributors ?

[novicr]

Note, trigger authentication also allows settings like oauthTokenEndpointUri + scope. These are not secrets and are likely to already be present in application configmap's. Current requirement means that people have to copy them into a Secret object.

[trzejos]

Other operators out there like trust-manager generate ConfigMaps rather than Secrets, and it should be preferable to reference the configmap directly rather than having to sync it to a secret. This can be useful for setting the ca parameter on the kafka scaler for example.

[tomkerkhove]

I think this is a reasonable thing to add and wonder how this did not come up earlier.

Even though it's not secure, it still has valid use-cases and storing secrets in environment variables is not secure either and still we support it. I'm in favor of this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[novicr]

This issue went stale. Seems there's agreement that allowing auth properties via ConfigMap would be useful and appropriate. Could this be picked up please?

[JorTurFer]

I'm still not sure if we should allow this, but I don't have any strong opinion, if someone is willing to add it, it's fine to me

[zroubalik]

I agree, Secret is not more secure than ConfigMap. Let's do this.

[tomkerkhove]

@novicr Are you willing to contribute it?

[wozniakjan]

hey @novicr I'd be happy to help, let me know if you intend to tackle the implementation as well or prefer to hand it over.

@tomkerkhove wrt implementation, what do you envision as desired API change, just adding array of ConfigMapTargetRef below SecretTargetRef?

keda/apis/keda/v1alpha1/triggerauthentication_types.go

Lines 78 to 79 in 1bcab6d

	// +optional
	SecretTargetRef []AuthSecretTargetRef `json:"secretTargetRef,omitempty"`

Or more generic with corev1.ObjectReference with jsonpath so people can use arbitrary CRDs in the future?

[tomkerkhove]

I'd personally go with ConfigMapTargetRef to have an easy to use API

[novicr]

Thanks for confirming. Unfortunately I probably won't be able to pick this up for couple of months. If someone is willing to take it, would be great. Otherwise, I'll take it when I can.

[wozniakjan]

If someone is willing to take it, would be great.

in that case, will try to take a look at it this weekend
cc: @zroubalik

[Sathya-omnius]

Hi Team,
we have a config-map created in templates , the Rabbitmq queue name is present in this configmap, can some one guide me how to access this queue name in Rabbitmq keda triggers.
apiVersion: v1
kind: ConfigMap
metadata:
name: amqp-settings
data:
max_priority: "1"
prediction_postprocess_result_queue: xyz

I tried using this from Keda documentation but the below code is throwing the exception
configMapTargetRef: # Optional.

• parameter: connectionString # Required - Defined by the scale trigger
  name: my-keda-configmap-resource-name # Required.
  key: azure-storage-connectionstring # Required.

can some one help how to consume the configmap data in to keda config trigers.

[wozniakjan]

I am not sure I fully understand your issue but I think you should configure the RabbitMQ queue name directly in the ScaledObject as described in https://keda.sh/docs/2.13/scalers/rabbitmq-queue/. This particular PR just allows setting authentication parameters in a ConfigMap for a certain TriggerAuthentication.

[Sathya-omnius]

HI,
Thanks for the reply, yes we can directly configure the queuename in scaled object but in our scenario the queue name is dynamic and will be present in configmap so I need to read the queuename from configmap and assign the value.

[wozniakjan]

I don't think setting other than authentication parameters for TriggerAuthentication from ConfigMap is supported at the moment. But can you configure your automation that changes dynamically the ConfigMap to change the ScaledObject directly too?