Improve UX of flowing API keys/env vars through infrastructure

[savannahostrowski]

Today, setting API keys as environment variables on infra is pretty convoluted --> e.g. copy the contents of your .env into the .azure/<env name>/.env file, add them to main.parameters.json, add params for the keys in main.bicep, pass params into api.bicep module and use in api.bicep secrets.

Talking to @ellismg and @weikanglim about this it seems like we might want to investigate how we leverage Key Vault more heavily here.

Internal link to pain points doc

[weikanglim]

investigate how we leverage Key Vault more heavily here.

Unfortunately, after some thought, I don't think this can be done easily without expanding azd's infrastructure provision to include a KeyVault seeding state.

The best short term is likely to source from .env / environment variables . I have a PoC here that simplifies it to just defining the settings in main.parameters.json with some bicep magic, in a format like:

main.parameters.json

    "apiSettings": {
      "value": {
        "settings": [
          {
            "name": "OPENAI_API_KEY",
            "value": "${OPENAI_API_KEY}",
            "secret": true
          },
          {
            "name": "OMDB_API_KEY",
            "value": "${OMDB_API_KEY}",
            "secret": true
          }
        ]
      }
  }

Note: The extra node for settings is required since @secure() can only be applied to bicep objects at this time.

But with this change, users can either do azd env set or move configuration into .env, and only need to define it in main.parameters.json.

[savannahostrowski]

Looking at that POC, we could generate all but what's in the main.parameters.json right? So then the user only really has to touch that single file or use azd env set to pass the keys? If that's true, that's a big improvement IMO and a great start.

[weikanglim]

Correct. User has to provide the value via env set, then wire up in main.parameters.json, but that's it.

I think this aligns with what @ellismg mentioned to me as what we can do short-term in passing as well.

[savannahostrowski]

I mean, that's much better than what we have today.

Longer term, it'd be nice if we could have a gesture to eliminate having to touch the Bicep at all but this is a start.

[vhvb1989]

using file.parametes.json won't work for the bicepparams approach

[weikanglim]

@vhvb1989 There's a direct translation to make this work in bicepparams world. This feature takes a dependency on env-var substitution, which is an existing dependency. Separate from that, we could easily move the same settings defined in parameters.json to bicepparams world.

The change hasn't been made to switch over, since we currently depend on secretsOrRandom for PostgreSQL.