When working with Azure, we should always put our secrets into a secure store, such as Key Vault. This ensures that we can limit who can see the values of our secrets, while still being able to work with them. How we work with these secrets is different over the various services, and in this article we will focus on Logic Apps, while other services will be explained in their own posts later on.
In Logic Apps we often will need some sort of secret, for example a subscription key for API Management, or a SAS key for Event Grid. In the scenario for this blog post we are going to send our secret to a RequestBin endpoint, so we can see that we indeed get the correct value.
Using a Managed Identity
First of all, Logic Apps has an out-of-the-box connector for Key Vault, which allows retrieval of the stored secrets. However, this connector has one major downside; it only supports OAuth and service principal authentication. This means we either need to have a user login, or create a service principal for the Logic App / connector.
Instead we would like to take advantage of using the recently announced Managed Service Identity (MSI) capabilities, which creates an identity in Azure Active Directory for our Logic App, which we can then assign rights on Key Vault for using Role Based Access Control (RBAC). Basically, a MSI takes care of all the fuss around creating a service principal. Setting up a Managed Identity is as easy as flicking a switch, which can be found on the Identity blade of any Logic App.
Configuration of Key Vault
Once enabled, the MSI can then be used in the Access Policies in Azure Key Vault. Here we can assign specific rights to the identity, which in our scenario is Get permissions on the secrets. Do note, that this means that the Logic App is then allowed to retrieve the values for all secrets in that particular Key Vault. As such, it is important to think about if the secrets need to be distributed over several Key Vaults.
Inside Key Vault we have the secret which we are going to send RequestBin. We use the endpoint to this secret without the version identifier, as explained in this blog post.
Implementation in Logic App
Now that our Logic App can access the Key Vault secret, let’s check how we can use this to retrieve the Storage Account primary key. As discussed before, the Key Vault connector currently doesn’t support Managed Identity, so instead we will use the HTTP connector.
Here we do a GET operation on the secret endpoint (remember, do not include the version, but do keep the trailing slash / ). Furthermore, in the api-version query string we send the version 2016-10-01, as this is the version where Managed Identity support was implemented. And finally, set authentication to Managed Identity, which will allow us to add the Audience parameter, which we set to https://vault.azure.net (without a trailing slash / ).
Now that we have the secret from the output of Key Vault in our Logic App, we need to make sure that it is not shown in the logging. For this we will use another recently introduced feature of Logic Apps called obfuscation, which hides the value of the output in subsequent actions. To enable this, go to the settings of the HTTP connector calling Key Vault, and turn on the Secure Outputs setting.
Next we can finish the message we are going to send to RequestBin. For this, we use the output from the HTTP connector, and grab the value property, by using the expression body(‘Get_Key_Vault_Secret’)?[‘value’] , where Get_Key_Vault_Secret represents the name of the HTTP connector used to connect to Key Vault.
We can now trigger the Logic App, to find the value of our secret in RequestBin. As you can see, this allows for a very secure way to work with your secrets, without the need to set up service connections or use user logins.