Enhancing Logic Apps security with obfuscation

Highlight

Introduction of obfuscation feature in Azure Logic Apps for input and output blocks allows for better secret management and enhanced security. This article will focus on presenting capabilities of this feature.

Intro

Introduction of Azure Logic Apps obfuscation for Input and Output blocks finally allows for proper security and integration between services without worrying about exposing critical information of the system in the logs and/or to unauthorized personnel.

Obfuscation of input or output blocks makes that

Data in the block is transferred normally to other actions
Data in the block is not visible in the Logic App logs
With diagnostic settings enabled data in the block is not transferred to external systems
There are some rules of chaining secured block data and developers should be aware of those, a bit more on this is described in the section below
There is currently no way to select specific variables to be obfuscated, only entire blocks. This means all variables in the block are hidden

The simplest one screen explanation of the feature can be captured as such

In JSON code view obfuscation can be configured as follows

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

But it is important to note that not every action supports obfuscation.

Chaining of obfuscated blocks

Using secure input and output feature has some important considerations to know. This is something I like to call action chaining. This means that securing output or input block of an action has impact on how inputs and outputs of all those following (downstream) actions will be seen.

Secure Outputs

If any output (hidden) are explicitly passed from an action which has enabled obfuscated output (hidden) to the next (downstream) action, then input block of next action will be obfuscated as well. Even if it doesn’t have secure input enabled.

Interestingly, some actions like Parse JSON only have Secure Inputs setting. Because of that enabling secure input automatically secures the output as well. In case secured input setting was not enabled but action received secured output from previous action then this action will be obfuscated but all downstream actions won’t. If downstream actions should be secured make sure secure inputs are enabled on this action as well.

Secure Inputs

If any output (visible) are explicitly passed from an action which has enabled obfuscated input (hidden) to the next (downstream) action, then input block of next action will be obfuscated as well. Even if it doesn’t have secure input enabled.

Simple example of this would be passing output statusCode parameter from HTTP action into the next action. This only happens if you use any outputs of previous action.

And the logs confirm this.

This is a bit complicated at start, but it is critical to be clearly understood because it will impact logging for logic apps.

Provisioning of Resources

This article only needs Logic App resource

Logic App

Go to Portal and hit create resource.
Search for Logic App and once found, click on it and hit Create button in the new blade window.
Fill in the fields

Name - this is the same of logic app resource.
Location - region of logic app; it’s best to place it in the same region as API management.
Log Analytics - this this example set this as Off but in case of production solution, should be set to On so that all the logs are transferred to Log Analytics resource.

Hit Create

Demo Logic App

Now that resources are created let’s create demo logic app which will be used to present the issue and the solution.

Open Logic App
Go to Logic App Designer and click on Blank Logic App
Search for request action group, and select it
Choose When a HTTP request is received trigger
In new block hit Add new parameter and select Method
In method parameter select GET method.

Note that this isn’t required. GET is just simpler to test and present the results than POST request which is default.
In new block hit Add new parameter and select Relative path
In Relative path parameter type in {secret}.
Hit Save

The issue

So, what is wrong with this design?

Grab the URL from the Logic App (it’s important to do this after saving)
Paste it into the browser and notice part of URL containing /invoke/{secret}
Replace {secret} with any string like MyBigSecret and hit enter
Open Logic App panel and find latest history run
Click on the run and open first block to see our secret in the output logs section

Obfuscation of Action Input and Output

It’s finally time to implement obfuscation.

Click on three dots (…) and select Settings in the popup menu
In the settings window select both Secure Inputs (Preview) and Secure Outputs (Preview) options and press Done
Notice how action has now an indicator showing that it has enabled obfuscation feature
In the logs now the input and output sections are hidden

And that’s it. Implementation itself is very easy, understanding the impact a bit more complex but it is a great feature and should be used in any solution working with highly sensitive data and credentials.

Conclusion

While this feature is still in preview it’s already providing a lot of value. Of one critical things that this enables is Key Vault integration. A long overdue, but it’s finally here, and I’m very happy about it.