0

I'm deploying an Azure Key Vault with a list of secrets. To achieve this, I used this quickstart-template.

This seems to work fine, but has some problems:

  1. The secret-value (provided in the parameters.json) is overwritten on each deploy
  2. I only want to create the secret, so an admin-user can provide the value for it. But removing the Value from the Properties-section leads to an error BadRequest / An invalid value was provided for 'value'.

The second issue is registered on github, but has anyone found a workaround for this issue?

BerDev
  • 1,457
  • 1
  • 8
  • 16

3 Answers3

2

This worked for me:

az keyvault secret set --vault-name=<vault-name> --name <secret-name> --file /dev/null
Alastair
  • 83
  • 8
0

I'd suggest looking at the API docs, not at the template reference (because its garbage). Here it says that the value is required.

So this is expected. it is not a bug.

Having said that, this means you need some other way of managing secrets in Azure Key Vault

4c74356b41
  • 69,186
  • 6
  • 100
  • 141
  • Thank you for pointing me to the API-docs. Although this indeed isn't what I was hoping for (I hoped there was a 'create secret' also). – BerDev Dec 17 '19 at 15:40
0

If you are looking for an admin to provide the password at a later date I'd recommend attaching an Access Policy to the KeyVault via ARM for the admin and having a dummy value in the password so they can just update in the portal.

Additionally if you aren't really keen on a dummy value or looking at automating the creation/insertion process I'd recommend using PowerShell to create and insert the secret to your Key Vault

For setting secrets via ARM it may look like:

 {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'),'/',variables('secretName'))]",
      "apiVersion": "2018-02-14",
      "properties": {
        "contentType": "text/plain",
        "value": "[parameters('secretValue')]"
      },
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults',  variables('keyVaultName'))]"
      ]
    },
DreadedFrost
  • 2,602
  • 1
  • 11
  • 29
  • 1
    A dummy value is no problem, the issue is that when repeating the deploy of the ARM-template will overwrite the values set by an admin. – BerDev Dec 20 '19 at 07:29
  • Okay I understand you better now. Have you looked at having your admin add these values as [release variables secrets](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=azure-devops&tabs=batch)? The link provided is for DevOps. Not sure how you are releasing your code. Essentially once added and secured they would then need to be referenced as override values on your release task for ARM deployments and end up replacing the dummy value with was defined in the release – DreadedFrost Dec 20 '19 at 12:59
  • I thought about that, but this won't work for us. It's not only an admin-password, but is about some more configuration-values that can change over time. Things like e-mailconfiguration. I don't like the idea of setting (and maintaining) al these things in my deployment pipeline. What I basically need is a KeyVault-seed-config, like a database-seed. – BerDev Dec 23 '19 at 07:07
  • 1
    After re reading your questions and comments I updated the answer to include how to set secrets via ARM. If the parameter doesn't change the value of the secret won't change (a "new version" is deployed in Key Vault but it is the same secret so if using get latest it won't be impacted). This might solve your non admin secrets and would be "seeded via ARM". As far as the Admin specific ones not sure of any other way besides override paramters, manually entering into the Key Vault, or a powershell script(Which could be a "seed script"). – DreadedFrost Dec 23 '19 at 16:47
  • Thank you. For now I will live with it. An option could be setting up a script that reads the current values from the KeyVault and modifies/overrides the 'values to set'. That could work for a fixed set of entries, but in our case there will be added secrets on a regular basis. For now we will add the secrets in the keyvault for each staging-environment. – BerDev Dec 24 '19 at 09:55