It’s too common to store sensitive data in Dataverse Environment Variables.
Do you?

These variables are usually readable by all users, depending on security roles. This poses a serious security breach…

We probably already know that Data Type on Environment Variables has an option called “Secret”; we are thinking, “that seems like a proper type for this sensitive value!” but when we select it, we see that there are a bunch of parameters that we need, and “only for now” we store it, e.g. an API Key, as a plain type “Text”.

Of course I will secure the API Key before we go to PROD!

Well, how often does that happen? #shame

---

Azure Key Vault

Azure Key Vault is a cloud service that centrally stores and safeguards sensitive data like passwords, API keys, and certificates.

Power Platform can keep these values out of the run history — if we configure it correctly.

Okay, we need to set up Key Vault and store the secrets there.

1. Go to Azure Portal:
   https://portal.azure.com/
2. Go to Key Vaults:
   https://portal.azure.com/#browse/Microsoft.KeyVault%2Fvaults

Key Vault for Dataverse

Create Key Vault

1. Select a Subscription and a Resource Group.
2. Set a general name for the Key Vault that will contain all secrets used in Dataverse. Of course, we can add several Key Vaults if we want, but to keep things simple, use just one per environment.

---

Admin for Secrets

1. From the top menu, click Add, then Add role assignment
2. Find role: Key Vault Secrets Officer
3. Go to Members, Assign Access to: User, group, or service principal
4. Find yourself or several users
5. Click on Review + Assign

Dataverse reads secrets

Start as above. The member is not a normal, visible user, but if you search for it, it will show up.

This user has some random Object ID, but if you search globally for that ID, you can open the “user” and see the Application ID, which has to have the GUID: 00000007-0000-0000-c000-000000000000

1. Select Role: Key Vault Secrets User
2. Find Member: Dataverse
3. Review + Assign

Name and Value are the important parameters.

But you can also set the activation and expiration date and time for when the secret should be available.

---

Subscription resource provider

The subscription we selected when we created the key vault needs to understand what Power Platform is. Why? That’s for a future article; just accept it for now.

1. Open the Subscription
2. Navigate to Settings, Resource providers
3. Find Microsoft.PowerPlatform
4. Register, if not already set

---

Power Platform (Apps)

Finally, it’s time to make the Key Vault secret values available in Power Platform!

The value will be generated as: /subscriptions/{subscriptionid}/resourceGroups/{resourcegroup}/providers/Microsoft.KeyVault/vaults/{keyvault}/secrets/{secret}

Default values can become breach risks!

We can save default references, but I definitely recommend that you do not use them! We should always specify it separately for each environment.

Using Secret Environment Variables

In a Cloud Flow, we can’t access the value by finding it in Dynamic content; they are not there.

1. You need to add an action: Dataverse: Perform an unbound action
2. Find Action Name: RetrieveEnvironmentVariableSecretValue
3. Set the technical name for the Environment Variable

The platform knows that secrets should always stay secret, so you should go to settings for this action and enable Secure Outputs.

The result of this action can now be used as any variable, but it will always be hidden because of this setting.

---

Key Vault Secret Readers

Earlier in this post, we set up the correct permissions for Dataverse and me to read Key Vault secrets. Those permissions were needed to configure the Key Vault secret and the Secret Environment Variable. Now we are getting closer to actually using the secret in a Cloud Flow; the connection may use a user account or a Service Principal, so we need to identify which identity is making the request and assign the proper permissions.

I have a Power Automate Cloud Flow that needs to retrieve the value of a Secret Environment Variable. I checked the Connection that the Connection Reference was using. I saw that the connection uses a Service Principal, which is good, but a tiny bit messy…

Service Principal

This is a bit of an unnecessary number of steps you have to do, but here we go:

1. In cloud flows, check which Connection Reference is being used for Dataverse
2. Look at the Connection Reference to see which Connection it is using
3. Go to the Connection, open it, and edit it; here you can find the Client ID, copy it
4. In the Azure Portal, do a global search for that copied GUID
5. We think GUIDs are super unique, but you can get more hits; look for it as type Service Principal
6. Open the Service Principal, copy its Object ID

Now we know who needs permissions.

Add permissions to the key vault

Go to the Key Vault and the Access control (IAM).

We need to add permission to read secret values:

1. Add a Role Assignment
2. Role: Key Vault Secrets User
3. Member: search by the Object ID you copied, or by name when assigning access to a user
4. Assign

In my Service Principal scenario, I also had to explicitly add permission to see the Key Vault:

1. Add a Role Assignment
2. Role: Reader
3. Member: as above
4. Assign

---

Examples

Fiction

• The flow retrieves the rappsol_SecretJuice Environment Variable, which points to a secret in RappToolsVault, and sends the retrieved value in an email.
• In the run history, we can see that the value is hidden.
• In the email I received, we can see the secret recipe for a magic juice. Security breach? Oh yes!
• Also note how the multiline value and formatting appear in the email. The secret is retrieved as a string; the receiving action decides how it is rendered.

Real world

I’m using secret environment variables to safely call my Azure Function from a Cloud Flow.

• The flow retrieves the Azure Function key through the Secret Environment Variable.
• When generating the URI for the HTTP call, it uses the retrieved value as the Azure Function API key.
• The key is stored and managed in Azure Key Vault instead of directly in the flow or a Text Environment Variable.

---

Only for Power Automate (almost)

After learning about this, I was pretty annoyed that this unbound action is intentionally limited to Power Automate Cloud Flows and Custom Connectors.

I would love to use it in code for my plugins, Custom APIs, and client-side logic.

Here we can find this lovely sentence:

This API is limited to being called within a
Power Automate Flow
and cannot be called directly in your code.

Microsoft Learn: RetrieveEnvironmentVariableSecretValue Action

---