Need a way to pass secrets as parameters

[Bpoe]

Summary of the new feature / enhancement

We need a way to parameters that are secrets to DSC. We should not have to write them to file on disk or pass them as a command line argument. Both of those can expose the secrets.

Proposed technical implementation details (optional)

I think the best solution would be to pass them in via stdin. However, today only the config can be passed via stdin. And how would we be able to pass both parameters and config via stdin?

[haodeon]

I use mostly envvar function

[SteveL-MSFT]

Parameters can already be passed in as JSON via command-line parameter, however, if the content is sensitive, this is not recommended as you can get the args passed to a command-line. Env var does protect against that and can be used today. Rather than having individual env vars per parameter, it may be useful to allow passing an entire parameters object via a single env var that the dsc engine accepts vs the config.

[michaeltlombardi]

Using a standardized environment variable, like DSC_PARAMETERS, which expects a JSON string adhering to the same schema as the parameters file, makes sense to me.

Separately, it would be useful to leverage a DSC extension or resource to retrieve secrets from a vault. While my preferred model would be an extension that adds a new configuration expression, like [keyVault("<vault-name>", "<secret-name>")], I think that extended expressions would be difficult to integrate with higher order tools.

[Bpoe]

Storing secrets in environment variables is not considered safe. It would be better to pass them via stdin. Can we either:

1. Introduce a flag to pass the template as a file and parameters via stdin
2. Introduce a combined scheme to pass both template and parameters via stdin

[Bpoe]

In regards to Key Vault, ARM has support for referencing Key Vault from the parameters file and a defined schema for it:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "adminLogin": {
      "value": "exampleadmin"
    },
    "adminPassword": {
      "reference": {
        "keyVault": {
          "id": "/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"
        },
        "secretName": "ExamplePassword"
      }
    },
    "sqlServerName": {
      "value": "<your-server-name>"
    }
  }
}

This would mean that DSC would need to be given an identity to access the Key Vault. My vote would be to leave this to a higher level.

[SteveL-MSFT]

There's a separate issue already to handle secrets within a config #685

@Bpoe why would using env var not be secure? You would not define the env var for the system or user, you create it as part of the env var block of the child process

[SteveL-MSFT]

Was thinking about this and I do think there's another option we could support. Currently, you can pass the config or resource input in via STDIN via -f - for the input, but this isn't supported for parameters. We could add -f - for the parameters as well, but this means that if you use both, then you must pass both as JSONLines instead of multi-line JSON. To simplify this, we can also require parameters first, and then the normal input.