azd env add secret

[vhvb1989]

Adding azd env set-secret

Description:

With this change, AZD allows customers to set Azure Key Vault Secrets (Akvs) within the azd environment.

Adding a Akvs

Folks run azd env set-secret <name> and they can select to either Akvs or select an existing one. For the Create a new Akvs, folks can select an existing Azure Key Vault Account or Create a new one. See the next table for the options for a user:

Flow	Description
1) Create akvs && Account && RG	Creating a new Resource Group with one Azure Key Vault Account and one akvs in it. User must select a Subscription, location and provide a name for the rg and kv account
2) Create akvs && Account && Existing RG	Creating Azure Key Vault Account and one akvs in it on existing Resource Group. User must select a Subscription, location and provide a name for the kv account
3) Create akvs && Existing Account	Creating one akvs in existing Key Vault Account. User must select a Subscription where the Key Vault Account is
4) Existing akvs	Selecting existing akvs in existing Key Vault Account. User must select a Subscription where the Key Vault Account is. *If no key vault accounts are found in the subscription, the create account option is turned ON

At the end of the flow, the akvs is persisted within the .env file (the azd environment) using the <name> provided by the user for the secret and the reference to the akvs as the value, which looks like:

NAME="akvs://key-vault-account-name/akvs-name"

Azd uses the prefix akvs:// as a way to identify a reference to an Azure key Vault Secret.

Using secrets

AZD can get the akvs value during the next flows:

1. azd provision + bicep + main.parameters.json.
   • Adding input parameter like:

@secure
input parameterName type

The type can be any supported type. The main requirement is to make the parameter secure.
AZD will not get akvs values for non-secure parameters.

• Create a mapping in main.parameters.json for the parameter to the secret from the .env. For example, when calling azd env set-secret OPEN_ID_KEY the mapping would look like:

"parameterName": {
  "value": "${OPEN_ID_KEY}"
},

• When AZD notices the parameter is secured, it will check if the value in the .env is an akvs reference and if yes, it will try to pull the value.

2. azd provision + bicep + .bicepparams. -> WIP

3. azd hooks:

   • When azd runs a hook, it uses its .env for the hook invocation. The hook implementation can access the values from azd .env as environment variables. However, if there are akvs in the .env, the values are NOT automatically converted to its value.
   • If folks want to get akvs values, they need to create a mapping in the hook definition, like:

hooks:
  preprovision:
    posix:
      shell: sh
      run: ./infra/azd/hooks/postprovision.sh
      secrets:
        OPEN_ID_KEY_VALUE: OPEN_ID_KEY

- On this example, azd will add one addional env var `OPEN_ID_KEY_VALUE` after pulling the value from the akvs reference.

Any other interaction with Azd environment will not resolve akvs into values. For example, running azd env get-values will display the akvs reference.  

[wbreza]

This is looking good but just have some questions and concerns about when and where the secret reference to secret value translation occurs.

[wbreza]

What is the expectation when a template runs in CI that has these vault references? Perhaps we should check if the project has a service principal id set and if so also automatically add secret reader rbac assignment to the SP? Otherwise it would need to be a manual process.

[wbreza]

I feel like the secret references => secret value should be a concern handled internally by the environment manager instead of the hook runner having to awkwardly inject the keyvault service to get the value.