Workflow Trigger API Keys for different environments

Workflows
, ,
1

I have two environments, develop and production.

What I'm trying to achieve:

  1. A single workflow that's triggered by our backend via CURL
  2. Our develop backend should trigger the workflow only for retool's develop environment
  3. And vice-versa for production backend, triggering only our production retool workflow

Requirement:
The api key for production will be placed in our secrets, and should only be visible by specific people in the company, for compliance/security reasons.

Problem:
I can't figure out how to have different api keys per-environment in a workflow. They all seem to use the same API key regardless of the environment I have selected.

This is an issue, as we'd need to give many engineers access to the workflow API key for triggering the develop retool workflow. But if the api key for develop matches the production workflow api key, we're breaking our company policy, giving access to staff that shouldn't have access to the production keys.

I would also ideally like to avoid having to create a separate workflow per-environment, as we want to ensure we're end-to-end testing workflows, and avoiding extra work by not maintaining two workflows for the same problem.

Is this possible with Retool? Or could you recommend the best workaround. Thank you.

2

Can the backend send a value indicating where it is coming from to the start trigger, and can you store the keys with an indicator for which environment they are coming from? If so, you could do something like:

let whichKey = [
  { development: retoolContext.configVars.devApiKey },
  { staging:     retoolContext.configVars.stgApiKey },
  { production:  retoolContext.configVars.productionApiKey },
].find((obj) => Object.keys(obj).includes(startTrigger.whichEnvironment));
3

@jg80 thanks for response.
I don't understand what the above would solve here, we'd still need to share the production, staging, and development workflow api key (which are all identical across envs) with each type of environment/all developers, right?

4

You would define configuration variables for the system one time (Manage configuration variables | Retool Docs) and then use them as appropriate when building without having to share them in the open. You would also be able to pass a variable whichKey in your workflow trigger that can vary by which source is sending the trigger and would tell the workflow which API environment to use. Maybe I'm missing something?

5

Thanks, let me try explain better :crossed_fingers:

The native environment switching trigger looks great, and we can use that as is perfectly.
But from what I can tell, there's no way of having a different workflow trigger api key per-environment, i.e all environments are using identical api keys for this trigger.

And that's problematic for us due to security policies, as we basically treat our own development secrets as if they're publicly accessible.
So if ever we had a breach of our own development secrets, we'd also have a breach here of our production retool workflow api keys effectively.

To illustrate, the values of the api keys here are identical between develop and production:

image
image1986×566 41 KB

image
image1970×558 41.1 KB

What I was expecting out of the box was (noting the api keys and env params here):

curl -X POST 
--url "https://api.retool.com/v1/workflows/workflow-id/startTrigger?environment=production" 
-H 'Content-Type: application/json' 
-H 'X-Workflow-Api-Key: retool_wk_PRODUCTION_specific_workflow_api_key'

curl -X POST 
--url "https://api.retool.com/v1/workflows/workflow-id/startTrigger?environment=develop" 
-H 'Content-Type: application/json' 
-H 'X-Workflow-Api-Key: retool_wk_DEVELOP_specific_workflow_api_key'

Edit: you may need to scroll across there to see what I mean by environment param vs api key differences

6

I suppose we could also:

  • have our backend send an additional secret in the request
  • and have some javascript step at the start of every workflow, that compares the secret with a custom retool environment variable secret
  • which would differ per environment.

It just seems like that's what the workflow api key's should be doing per-environment by default, right?

For example, Stripe's api, you'd have one account, but to hit the test vs production stripe api, you'd have two very different api keys.

So worst case if a developer that might have Stripe or Retool test keys (stored locally on their local env on their laptop), loses their laptop at the airport, we're not in an absolute crisis having to rotate all our production keys as well.