How to use Environment Variables with AKV Secrets in the CI/CD Pipeline when deploying applications

Overview

We began the new year, announcing the preview of a capability in Dataverse, which allows environment variables in Power Platform to reference secrets stored in Azure Key Vault. Since the preview, we have had a lot of users asking on how this preview would work with their ALM pipelines. This document highlights a general flow on to make it work. The ALM pipeline being executed is being run under a service principal (SPN).

Why Azure Key vault?

Imagine you have an application that requires authenticating a data source with a particular client id or a secret key. You would not want to expose those secret values to other authors or users of your application. In such a case you would want to store these sensitive values, which are important to the functioning of your application, in Azure Key Vault. The example used in this blog to support secrets, we are storing the clientid and authentication key as secrets in Azure Key vault and referencing those values when deploying them from one environment to the next. This blog highlights the assumption that data sources used in development environments are different than the similar data sources used for QA, which requires updated values for your clientid and authentication key to such data sources. For the basic concepts of Azure Key vault please refer to the documentation.

Figure 1: Example of a secure application using Azure Key Vault for storing application secrets

Grant the SPN for the CI/Cd Pipeline access to the target environment Key Vault

In this example, we have a ServiceNow connector, which is used in an application within Power Platform, this is similar to the setup mentioned in the blog. Two different ServiceNow instances are used, one for development and another for testing purposes.

Figure 2: Flow of the ALM pipeline sequence

The service principal account that you are using needs to have read access to the target environment’s Azure Key Vault. In this example I have a production key vault that I use to secrets for my QA and Production environment (it is recommended that you have separate Key Vaults for Dev, Test, and Production not like my setup which is a demo environment)

Figure 3: Provide SPN account being used to run the Pipeline reader access

SPN account needs access to the target environment

To make sure that the SPN can deploy to the target environment, make sure that the SPN has access to and the right role setup in the target environment, which is typically the System Administrator role.

Figure 4: SPN access to the target environment to deploy the solution

setting up the Azure DevOps service connection

To set up the service connections in Azure please go to the project settings and select Service Connections.

Then proceed to specify the connection details for the environment

Figure 5: Specifying details for the service connection

You can do this for both your Development and QA environments, or any other Power Platform environment you might be using in your pipeline. Ideally, you should have different SPN accounts that deploy to QA and to Prod and not use the same SPN account if possible.

Setting up your solution

You can set up the environment variables with references to Azure Key Vault Secrets using the following blog from Sameer Chabungbam

Easier deployments of Custom Connectors | Power Automate Blog (microsoft.com)

Using Azure DevOps to store the solution to source

So, we will create a pipeline that will extract the solution from the development environment and commit the artifacts to source control. In this case my pipeline exports the solution from the development environment and checks-in both the unpacked solution and the solution zip into the repository. For more details on how to setup Azure DevOps with Power Platform build tools please to this link

Figure 6: Getting solution from the development environment and committing to source

Inside the Git repository in your Azure DevOps environment, you will see the following:

Both the SvcNow.zip (solution zip file) and the unpacked solution file are now in the repository. For secrets, we recommend that you do not create default values with the location of your secrets and only store them as current value.

Create the deployment settings file and provide target values

To create the deployment settings file, you can proceed to open the repository in VS code with the Power Platform extension installed and run the create-settings subcommand under the Power Platform CLI command. Running the create settings file creates a settings json file that can be populated with the values for the target environment.

Figure 7: Creating the deployment settings file

Open the new settings json file and supply the values for the target environment. Keep in mind the string value on how the path to the Azure Key Vault is provided.

Figure 8: update setting file with the target values

Check in the changes into the repository and let us proceed to deploy the solution into the target environment.

Running the deployment

Once the changes are committed into the code repository, as shown in Figure 9, we can proceed to start the deployment pipeline.

Figure 9: checked-in deployment settings file

Now in the pipeline menu let us create the Power Platform Deployment Pipeline to deploy to QA. The Key tasks here are the pack, Solution Checker, and the import command (but don’t forget the tool installer as your first step).

Figure 10: Solution import settings in the deployment pipeline

Make sure that you have selected the “Use deployment settings file”, this is a key operation to make this pipeline work with Azure Key Vault for the target environment.

Figure 11: Example of a deployment run into QA

Once the deployment is done you can now check the solution in the target environment with the appropriate values.

Figure 12: Changed Key Vault values for the Target QA environment

In Summary

This Azure Key Vault capability, in environment variables referencing secrets in Azure Key vault is still in preview, and the experience that we have shown here, in this blog, can still change before we GA this capability. This experience is to address the use case which allows applications to securely store their secrets in Azure Key Vault without any modification. We made this capability available to get early feedback. Please give us your feedback at ISVFeedback@Microsoft.com or in the Powerusers community.