Open Benly-walter opened 2 months ago
any updates on this please?
yeah, I ended up setting up secrets ClusterTriggerAuthentication for each of my service bus instances because this didn't work
Hello We don't support it but there is native support to connect KEDA directly with your keyvault to read the secret from there. I mean, KEDA doesn't support reading the actual pod envs because they are mutated during the scheduling and KEDA works with the workload spec and not the mutated pod spec, but it has support to directly go to the Key Vault and read the secret from there, so you can get rid of k8s secrets. Currently, you can use cross-tenant Workload Identity IRRC. @pauldotyu implemented it if I'm not wrong
Proposal
Requesting this feature to have support for environment variables injected via akv2k8s directly into the container application using the connectionFromEnv trigger parameter.
Currently, KEDA does not seem to support environment variables managed by akv2k8s. We inject the SharedAccessKey for the service bus directly from Key Vault as environment variables. During a test migration, I noted that KEDA stopped working, and the following errors were seen in the KEDA keda-operator-metrics-apiserver pod logs.
Use-Case
This would help us eliminate native secrets altogether in our setup. We have service bus queues spread across tenants in Azure, the metrics of which are used by our app to auto-scale. All the SharedAccessKeys are currently stored as a single native Kubernetes secret.
We are unable to use Azure AD Pod Identity or Azure AD Workload Identity providers (using managed identity for our AKS cluster) due to the cross-tenancy. Having multiple SPNs configured to allow access is also not an option in our case.
With akv2k8s, all of these secrets can be moved to a key vault in the same tenant where the AKS cluster runs, and access between them is already working over managed identity.
Is this a feature you are interested in implementing yourself?
No
Anything else?
No response