Does it make sense to populate extra environment variables?

[farzadmf]

Is your feature request related to a problem? Please describe.
It is impossible (well, technically not impossible, but a bit less convenient) to use an Azure KeyVault as the secrets provider since it requires some additional environment variables to be populated.

According to the documentation, if you don't want to set AZURE_KEYVAULT_AUTH_VIA_CLI to true, you need to use Azure environment variables in order to have access to the KayVault.

From here, we can see that these are:

• AZURE_TENANT_ID
• AZURE_CLIENT_ID
• AZURE_CLIENT_SECRET

Since some env vars are being populated (ARM_CLIENT_ID etc.), I thought maybe these env vars could also be populated from the service connection we're using for the task.

Describe the solution you'd like
I think it can be something automatic (or maybe a checkbox to indicate whether we want to populate these variables). Assuming that the service connection we're using is the one that has access to the KeyVault, it would be more convenient to have these variables automatically populated

OR:

Maybe not directly related to this, but, maybe a better (IMO) and a more generic solution would be a way to specify additional environment variables we want to pass to the task. This way, we have good flexibility and we can even pass required information for login too (ie, AZURE_STORAGE_KEY and AZURE_STORAGE_ACCOUNT); something like:

- task: Pulumi@1
  # ...
  envVars:
    AZURE_CLIENT_ID: '...'
    AZURE_STORAGE_ACCOUNT: '...'
    # ...

Describe alternatives you've considered
It is possible to set these variables as job variables and then, they will be accessible as environment variables:

job:
- variables:
    AZURE_CLIENT_ID: '...'
    # ...
  steps:
  - task: Pulumi@1
    # ...

Additional context
I think the option to specify additional environment variables is a good solution (of course, that's just my personal opinion)

[Gerrit-K]

OR:

Maybe not directly related to this, but, maybe a better (IMO) and a more generic solution would be a way to specify additional environment variables we want to pass to the task. This way, we have good flexibility and we can even pass required information for login too (ie, AZURE_STORAGE_KEY and AZURE_STORAGE_ACCOUNT);

+1 for that! It's currently pretty difficult to deploy to a stack that is backed by an azure blob storage using this task. The described workaround using variables doesn't work if you (IMHO rightfully) model the storage key as a secret, because you're only allowed to either use template $(macros) or map them in an env block directly (see here).

In case this gets implemented, I'd suggest to use the key env though, as it seems to be the default for most other (including official) tasks.

EDIT: the docs even (falsely) claim that this would work:

You may still use the env directive to map any other environment variables you wish to make available to your Pulumi app.

[praneetloke]

The latest version 1.0.7 (released today) should allow you to specify additional env vars to be passed to the execution environment of the pulumi login command. As @Gerrit-K mentioned, you could just use the env: key to specify additional env vars at the step-level and it should be passed to the shell that is executing the login command. In addition, v1.0.7 also now sets 3 additional env vars if an Azure Service Connection is used: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET.