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
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.
apiserver received an error that is not an metav1.Status: &status.Error{s:(*status.Status)(0xc000e4c6e0)}: rpc error: code = Unknown desc = error when getting metric values no matching metrics found for s3-azure-servicebus-endpoint
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: