You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the introduction of TLS support for external scalers in kedacore/keda#4407, ScaledObject resources may now include both a CA certificate to validate the certificate authority used by the external scaler server as well as its own certificate. However, there appears to only be one value for passing gRPC TLS secrets in the KEDA helm chart: grpcTLSCertsSecret. Specifying both the CA cert and the client cert would require two secrets, volumes, and volume mounts for the Deployment resource.
Am I missing something? I suppose you could use the hashiCorpVaultTLS value as a workaround.
Expected Behavior
The ability to pass multiple secrets, perhaps as an array like grpcTLSCertsSecrets? Or if that's confusing given the existing value and wanting to avoid removing it as a breaking change until v3, add a new value as the current one was historically used for the CA only, like grpcKedaTLSCertsSecret or something?
For example:
grpcTLSCertsSecrets:
- name: serverCertsecretName: kedaTlsCertmountPath: server
- name: caCertsecretName: scalerTlsCaCertmountPath: ca
Actual Behavior
Only 1 TLS secret may be specified today for the Helm chart that's designated for gRPC communication with external scalers.
Specifications
KEDA Version: >= 2.11.0
Scaler(s): External Scalers
The text was updated successfully, but these errors were encountered:
Hi
You can create all the extra secrets that you want using [extraObjects](https://github.com/kedacore/charts/blob/main/keda/values.yaml#L623) and mount them in KEDA with volumes.
Using this approach, you can mount all the secrets that you want in KEDA pods, then you just need to reference them.
I'm not totally sure if this is the best approach because maybe reading base64 encoded value from secrets scales better, but currently is a way to do it
Thanks @JorTurFer! I will close this issue, as I somehow completely missed the volumes.keda.extraVolumes and volumes.keda.extraVolumeMounts! My mistake! These volumes can be easily be used for both certificate secrets for mTLS. However, perhaps these different volume helm values can be reconciled in the future: does the chart need both grpcTLSCertsSecret and volumes.keda.extraVolumes?
Honestly, I have noticed that key, I thought that you proposed that key as new 🤦
I have checked the history and that parameter is there since the beginning 😄 I think that it's not used because I don't see that option in KEDA core, I guess it's because you could read from it as part of the external scaler directly. I'd use the volume parameters I told you before because it's more flexible.
With the introduction of TLS support for external scalers in kedacore/keda#4407,
ScaledObject
resources may now include both a CA certificate to validate the certificate authority used by the external scaler server as well as its own certificate. However, there appears to only be one value for passing gRPC TLS secrets in the KEDA helm chart:grpcTLSCertsSecret
. Specifying both the CA cert and the client cert would require two secrets, volumes, and volume mounts for theDeployment
resource.Am I missing something? I suppose you could use the
hashiCorpVaultTLS
value as a workaround.Expected Behavior
The ability to pass multiple secrets, perhaps as an array like
grpcTLSCertsSecrets
? Or if that's confusing given the existing value and wanting to avoid removing it as a breaking change until v3, add a new value as the current one was historically used for the CA only, likegrpcKedaTLSCertsSecret
or something?For example:
Actual Behavior
Only 1 TLS secret may be specified today for the Helm chart that's designated for gRPC communication with external scalers.
Specifications
The text was updated successfully, but these errors were encountered: