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
GM Dynamics Consulting 