How can I correctly pass the API_KEY as an environment variable in AKS connectors’ PODS? I used the command [kubectl create secret generic my-secret --from-literal=API_KEY=my-actual-key -n my-namespace], and it is visible under the pods environment as API_KEY: secret(my-secret)[API_KEY]. The attached screenshots confirm that the API_KEY value is displaying correctly.
I deployed the connectors in AKS using my own Helm chart. When I hard code the API_KEY from Camunda desktop modeler, the solution works. However, this is not the recommended approach to pass the API_KEY.
Now, I am accessing it as shown in the attached screenshots, but I encounter an error. The error message is: “User request failed to execute with status 401 and error ‘SendGrid returned the following errors: The provided authorization grant is invalid, expired, or revoked’.” What could be causing this issue, given that the API_KEY value is not being retrieved successfully? @Niall@nathan.loding
@tanaychauli - Connector secrets are not the same as Kubernetes secrets. Connector secrets are, by default, environment variables that are injected when the Connector is invoked. They are secret from the modeling process, and managed outside of the modeling process.
If you want to use Kubernetes secrets for Connectors, you could write your own “custom secret provider” that retrieves the secrets from Kubernetes (details in the link above), but managing secrets using the default methods seems to work well for most users.
Thank you for sharing the idea about the custom secret provider. However, I’m seeking a more straightforward approach. When I execute it in docker-compose, I can access the API_KEY using the syntax “{(secrets.API_KEY}}” directly from the modeler. How do people manage secrets for Helm Camunda-platform deployments? Considering many people might be facing a similar scenario, do you have any suggestions other than the one mentioned above?"
Hi @tanaychauli - the straightforward approach with Helm/k8s is to do it exactly how it’s done in Docker: with environment variables. If you’re asking how do you manage getting the secret values into the environment variables, that really depends on your current workflow. You can use kubectl set env, for instance. Another alternative would be try to reference Kubernetes secrets in Helm (example) but I’ve never tried this approach myself.
@tanaychauli - in your first post, you said you were creating that value with this command: kubectl create secret generic my-secret --from-literal=API_KEY=my-actual-key -n my-namespace … that is a Kubernetes secret, and not the same as a plain environment variable. I believe you need to use kubectl set env.
