If you're using Azure Resource Manager templates to manage an Infrastructure as Code or Continuous Deployment workflow you've no doubt had to deal with marshalling secrets between a “secret store” and tools to deploy templates to Azure. A not so uncommon pattern is putting those secrets into parameter files which are then checked into source control which is, well… not the best practice for managing secrets.

In Azure Resource Manager templates you can provide references to secrets in Azure KeyVault and in the 2.9 Azure SDK you can use the tools available in VS to make this as simple as saving the secret. There are a few steps needed to make this work, but we’ve made it easy for you in this release.

1. Create a Key Vault for the secrets you want to use during deployment
2. Put secrets into the vault
3. Set properties on the Key Vault to allow Azure Resource Manager to retrieve secrets during deployment
4. Author a deployment template to reference the secureStrings in the Key Vault

Note also, the user performing the deployment will need Read permissions to the secrets in the vault. So if you're using a service principal to deploy in an automated workflow, that service principal will need access to the secrets you want to use.

Here's a quick walkthrough of how to use Visual Studio to author templates to use secrets from Key Vault.

First, you need to have an Azure Resource Group project that you want to deploy. If you haven't created one before you can read a quick overview of that here. For my example, I've created a project based on the Virtual Machine Scale Set and will use KeyVault for the admin password of the virtual machine.

Once the project is ready to deploy, right-click on the project node to start a new deployment.

From here, click the Edit Parameters… button to see the available parameters in the template.

I've already filled in all the parameters, except the one for the password. Rather than type in a value, I'm going to use the KeyVault button to select a secret from a KeyVault. From here you may notice a few things…

First, if you don't have any Key Vaults in your subscription, there is a script that will create one for you. Currently, you cannot create Key Vaults through the Azure Portal so scripting is the way to go. By using the script, you can see *exactly* what's being done as well as modify and reuse it in other workflows. If you prefer templates, you can also create a vault (and secrets) using a template.

Another thing you might see, if you already have Key Vaults in your subscription, is that the vaults you have may not be enabled for use during template deployment. This is the “enabledForTemplateDeployment” property you see used in the scripts above.

If you select this vault, Visual Studio will set the property for you, if you have permissions to do so. Note that this property is for the entire vault and all secrets in it, not just the one you select for deployment.

Once you've selected a vault, you can select any secret you have in the vault or create a new one.

Now back on the Edit Parameters dialog, you'll see a watermark for the secret value to let you know that you're using a reference to the secret and not a literal value in the parameters file.

If you want to see the way this is referenced in the JSON, just open the parameters file and you can see what's changed:

Also, note, that there are no changes to the template itself to make this work, only the parameters file. So you can change vaults by using different references in different stages of the workflow by just using different parameter files. Or each developer may have their own resource group or environment with different secrets.

That’s all there is to it. As always, let us know if you have any feedback.