DISCLAIMER: I’m assuming you already have created your Azure Key Vault, and stored secrets/certificates in it, if you are not familiar with this (it is super-easy) you can check this article: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-get-started
This is a short but, at least for me, very useful topic for keeping your deployment secrets more secure. Most of the times, keeping secrets as secret variables on your VSTS definitions is enough, at last, they can’t be “human read” once set the value.
But sometimes, the person who keeps the secret won’t be editing the VSTS Release, and of course they are not going to tell anyone the secret also. If you have an Azure account, well we are talking about VSTS so probably you have it, you have Azure Key Vault, here you can store, secrets and certificates, securely in Azure, only users with the proper rights will be able to access them, but we have also a task in VSTS Releases (and Builds) which can retrieve this secrets (if your VSTS SPN connection has the proper rights) and use them as variables in your Releases/Builds:
How this works? when using this task, we have to configure the Azure Subscription Connection, Key vault name and a filter (comma separated values) for the names of the keys/certificates you want to retrieve or you can use * to retrieve all.
When it retrieves the secrets it will store them in VSTS variables, which can be accessed in subsequent tasks with the usual format $(name). To be more clear, let’s say you have a secret in your Azure Key Vault which is called “sqlPassword”, when retrieved by this task, it will create a variable which we can in subsequent tasks as $(sqlPassword). Of course this task must be called before trying to use the variable.
But first of all we have to give, explicitly, permissions to the SPN used by VSTS to connect Azure Subscription, to the desired Azure Key Vault. This can be done thought the portal or via this Powershell:
Login-AzureRmAccount -SubscriptionId <Subscription ID>;
$spn=(Get-AzureRmADServicePrincipal -SPN <Service Principal Id>);
$spnObjectId=$spn.Id;
Set-AzureRmKeyVaultAccessPolicy -VaultName <Vault Name> -ObjectId $spnObjectId -PermissionsToSecrets get,list;
In this Powershell we have to change <Subscription ID> to the ID in which our Key Vault exists, it must be also the same subscription we select as subscription when we configure the task in the previous step.
Also we need to change the <Service Principal Id> to the ID of the SPN we are using to connect to Azure in the task configuration. To get it you have to go to Services in VSTS:
Select the endpoint you are using to connect to Azure and select Update Service Configuration, so you will see the value:
As you can see we can also get the Subscription ID here if in doubt.
Possible problem: if when executing this Powershell you get this error, you need to update to the latest version of Azure Powershell (https://github.com/Azure/azure-powershell/issues/4953):
WARNING: Could not load file or assembly ‘Microsoft.Data.Services.Client, Version=5.6.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’
And that’s all, if you configured everything correctly, when you run the Release you will be able to access your secrets as VSTS Release/Build variables to use them across the Release/Build, so go and store your secrets securely in Key Vault.