Just came across the Operate Connector and attempted to connect to it using secrets for CAMUNDA_CLOUD_REGION and CAMUNDA_CLOUD_CLUSTER_ID.
I’ve confirmed these same secrets work with the REST Connector.
Operate Connector seems to go ahead and append the Strings together in the URL before trying to resolve secrets and I end up with an error indicating that a secret was attempted to be found like:
Secret with name ‘CAMUNDA_CLOUD_REGION.operate.camunda.io/secrets.CAMUNDA_CLOUD_CLUSTER_ID/v1/variables/search’ is not available
Please make sure you use the right syntax for the secrets. Take special care to the curly brackets.
See the documentation about using the secrets here: Using Connectors | Camunda Platform 8 Docs
I deleted my last post as I realized I had a space between secrets. and CAMUNDA_CLOUD_REGION
Here’s what I found for the Operate Connector:
Region requires the {{ }} notation.
Cluster ID requires the {{ }} notation.
Client ID and Client Secret will resolve with or without the {{ }} notation. ← Working without {{ }} is what I’ve witnessed for the Kafka and REST Connectors as well.
Side note: The documentation also claims that this {{}} syntax can be used in FEEL expressions when wrapped in quotes but that has never worked for me. It just sees it as a plain string:
Secrets are not variables and must be wrapped in double quotes as follows when used in a FEEL expression:
I found another problem with secrets for the Operate Connector.
It seems it can only reference secrets defined in the Console and not environment variables.
The Kafka Connectors are able to use secrets defined as environment variables in my docker image but when trying to reference those same secrets with the Operate Connector, I get an incident in my process instance:
Failed to load secrets from secret manager
Once I added the same secret name in my Console defined secrets, it resolved successfully.
Hi @slate83, it seems you are trying to use secrets managed by the Console in the SaaS environment in a runtime running in Docker. Please be aware that the runtime in Docker is not aware of any secrets managed by the SaaS console. Its also important to notice that secrets managed in your local Docker image are not accessible by the SaaS runtime either. If you define a secret as an environment variable in your Docker environment like: MY_SECRET you will be able to access it using the secret syntax: {{secrets.MY_SECRET}} in every connector running in your Docker runtime.
Its also important to notice that if you “just” run your Docker runtime next to the SaaS runtime both with request jobs from the zeebe instance despite you Docker runtime not able to execute them properly in case a job references any secrets.
I have Connector Runtime in Docker with only 1 connector type, Kafka. This is the type of connector that was successfully accessing those environment variables from Docker.
When I implemented the Operate Connector, I did not think about this and so it was the SaaS based Connector Runtime picking up those jobs.