Image by Cloudypixel on Unsplash
In this post, I’ll show you how you can secure your secrets within your Logic Apps!
Background
You may recall in my post Azure: Trigger a WebJob with Logic Apps and Kudu - Part 2 a couple of months ago, I provided a guide on how to run a webjob when a Kudu deployment completes in an App Service WebApp - pulling secrets/credentials out of KeyVault as required, all triggered by a webhook running a Logic App.
At the time, one thing that bugged me was that if you were to look at the run history of the logic app, you could see all inputs and outputs in plaintext as below:
That might be fine for me using a pay-as-you-go subscription only used by me, but if you’re in a multi-tenant, multi-user corporate environment, you might not want that sort of information available to view easily.
The Solution
After some googling I found myself at yet another helpful Microsoft Docs article which would suggest that I’m not the first person to have that thought!
It seems that you can in fact take a number of security precautions to mask/obfuscate data, including:
- Restrict access to run history data by IP range
- Hide inputs and outputs in run history by obfuscation
For my uses, I’m going to explore option 2 - hiding inputs/outputs in history by obfuscation, so first of all, navigate to a Logic App in the portal that you want to enable this for.
Now, click on Edit to edit the logic app:
The settings to secure inputs/outputs are at individual logic app action level.
In the case of the logic app I created in the post linked to above, I have several HTTP actions that make a call to KeyVault to retrieve a secret and use it in a later action, so lets click on the ellipsis (…) beside the first of those actions.
Click on Settings
You’ll now see there are options for Secure Inputs (Preview) and Secure Outputs (Preview)
Let’s turn those both on, like so:
Then scroll down and click on Done:
An important note from the article:
Make sure that you turn on Secure Inputs or Secure Outputs in downstream actions where you expect the run history to secure that data.
For now let’s not change any of the downstream actions, and just click on Save:
We can see that the action we just amended how has a padlock icon on it:
Now let’s click on Run and see what effect that had.
First thing I notice is that when you expand the action we just modified, we can’t see any of the inputs/outputs (I wonder why that might be!):
Now the run worked, so we know the masking doesn’t affect the operation of the app, but what do the other actions look like in the run history.
The next step was a Parse_JSON action and looks like this:
So although we haven’t enabled the Secure Inputs/Outputs on this action, because it uses Secured Inputs or Secured Outputs, those are still hidden downstream of the action where they were secured.
Next we have another HTTP action:
We can see the fields here because nothing here was secured on first use.
Now on the next Parse_JSON that parses the output from the 2nd HTTP action, again we can see the inputs and outputs:
If I check that last HTTP action - all fields are visible except the password field, because Logic Apps is clever enough to recognise that it should hide passwords and it was declared in a password field in the HTTP call definition:
You may be wondering though we we can see the username which was set in the first HTTP call and we enabled Secure Inputs/Outputs for that action.
Because that downstream action explicitly uses a Secured Output as input, that input is not hidden as it was for Parse_JSON etc.
So if I want to hide it everywhere I need to explicitly Secure it everywhere I wanted it to be hidden.
If I then enable Secure Inputs on all my HTTP actions and Secure Outputs on all but the last HTTP action - all sensitive data used during the run is hidden, but I still see the final output, which is useful for logging/troubleshooting:
Things to be aware of
There are a few considerations for use as follows:
- When you secure the inputs or outputs on a trigger or action, Logic Apps doesn’t send the secured data to Azure Log Analytics. Also, you can’t add tracked properties to that trigger or action for monitoring.
- The Logic Apps API for handling workflow history doesn’t return secured outputs.
- In an action where you secure inputs or that explicitly uses secured outputs, and this action returns a response with outputs that include this secured data, you have to manually turn on Secure Outputs in this action to secure these outputs.
- Make sure that you turn on Secure Inputs or Secure Outputs in downstream actions where you expect the run history to secure that data.
I hope you found that useful - just remember that these aren’t on by default, you need to enable them (and they may not be required/suitable for all use cases).
As ever, thanks for reading and feel free to leave comments below.
If you like what I do and appreciate the time and effort and expense that goes into my content you can always 