In my previous article I showcased how you can use Environment Variables to dynamically retrieve secrets straight from Azure Key Vault, and pass it to HTTP action in a secure way. After you successfully did the implementation, you might have started to wonder how do you then introduce this type of Environment Variable into your Azure DevOps pipelines, and succesfully populate the correct value in your target deployment environment(s)? Don’t worry, I will guide you through this process as well 🙂

I have briefly gone through the deployment settings configuration in my earlier article regarding connection references. Environment Variables follow same practicalities to certain extent. They are included in the same settings file as the connection references, and similarly the values are populated to target environment during the import.

Azure Key Vault practices

In my previous article I explained the basic concept of how Azure Key Vault can be utilized with the Environment Variables with Azure Key Vault secrets. In addition to the configuration and described in that article, Azure DevOps will require one additional role assignment.

The same service principal which you are using in Azure DevOps for the service connection to Power Platform is the same service principal for which you need to assign the Key Vault Secrets User -role. In my example, the service principal i am using is “SandboxTuomasAntoSP”, which now has correct role for the corresponding Key Vault.

If you do not assign this role, DevOps will not be able to set the value into the environment variable due to lacking permission to the corresponding Key Vault. Note that this refers to the Key Vault which the environment variable in the target environment will utilize! Not the Key Vault used for the initial setup, such as the one for dev environment.

Preparing the deployment settings

If you read the earlier article regarding connection references, you should now be aware of the fact that in the deployment settings -file, you will always define the TO-BE values, which will be applied upon the deployment through Azure DevOps.

I will clarify the mapping of the environment variable definitions to the deployment settings.

Syntax for the Environment Variable Value in the deployment settings JSON-file can be found below. I have added the tags <Description_here> to the syntax for the parts you need to fill in. Copypaste this into your deployment settings, for the corresponding environment variable Value, and replace those tags to match your setup.

NOTE: You don’t need those angle brackets in the updated value, I just included them to the example to highlight the replaceable contents better.

“/subscriptions/<Azure_Subscription_ID>/resourceGroups/<Resource_Group_Name>/providers/Microsoft.KeyVault/vaults/<Azure_Key_Vault_Name>/secrets/<Secret_Name>”

Below you can see how exactly you can find the values from the UI, assuming you already configured the variable there, and where those values should be placed in syntax.

Preparing the solution, and deploying it

Now that you have prepared the deployment settings, there is still an important thing to be done in the solution where you have the environment variables which you are going to be deploying.

Since I have used the “Current value” approach with the environment variable, and I don’t have any default values set, then by default when deploying this to the target environment through DevOps, the system will associate the environment variable with the same current values as you had in your source environment if they are part of the solution. This is the case even if you have the deployment settings configured correctly. The values in the solution seems to override whatever you have in the deployment settings.

You can also see this by examining the extracted solution in your version control (or locally if you extracted the file into your local drive). With the most simple configuration, the extracted contents regarding environment variables looks like this:

You can see there is a JSON-file called “environmentvariablevalues.json“, which contains the current value of that environment variable you currently have configured in your source system. This value in this specific file would be the value which would be set into the target environment of your deployment.

If you have environment specific Azure Key Vaults (best practice I encourage you to also follow), with environment specific secrets, this is a huge problem if you don’t take appropriate actions.

This means that you will see those three little dots right next to the Secret Name, or if you are using “normal” variable like having Data type: Text, if will be next to the value box anyway.

Clicking the three dots will give you two options, and the one you should select is “Remove from this solution”. What this does, is that it will still retain the current value in the environment, but it is not anymore moved inside the solution. This will then allow DevOps to fill in the correct value which was defined in the deployment settings earlier.

After removing the current value from the solution, you will get a prompt which states it was removed, but can be added back simply by clicking the “Add existing”. At least in my opinion, a really easy way to govern these values.

Now let’s do another build with the current value removed, and examine the results.

Extracted solution reveals how this reflects to the solution structure in practice. Notice how the environmentvariables.json -file is no longer part of the solution structure in file level. This now means that Azure DevOps is able to apply the new value from the deployment settings, so that the environment variable will be set correctly in the target environment.

Now everything should be ready for that deployment with Azure DevOps pipelines!

I hope this helps anyone struggling with this same topic 🙂

Find more great blogs here.

About the Author:

My name is Tuomas Anto, and I currently work at Fellowmind Finland as Competence Lead & D365 Solution Architect.

I could describe my competences as being multitalented and solution oriented tech expert with a passion for Microsoft technologies. I’m the one who usually gets the call after the easy jobs has been done 😉

In the past I have also worked in various leader and manager roles, such as Development Manager, IT Manager, Team Lead and Unit Lead, in which I have also demonstrated leadership skills along with wide-scale technology knowledge.

When i’m not busy creating business value with kick-ass solutions, I like to spend time with my kids (3 boys and 2 girls), or doing the WoD at my favourite Crossfit gym!

Visit my LinkedIn profile below for more details about my skills, competences and certifications! And feel free to drop me a message, it’s always nice to connect and network with new people.

Reference:

Anto, T (2024). Using Azure DevOps to deploy Environment Variables with Azure Key Vault secrets. Available at: https://tuomasanto.com/2023/10/20/using-azure-devops-to-deploy-environment-variables-with-azure-key-vault-secrets/ [Accessed: 3rd September 2024].