Protecting Application Credentials when implementing Modular Azure Functions with Microsoft Flow

This weekend I was attempting to rework some older Azure Automation tasks I wrote some time ago that were a combination of PowerShell scripts and Azure (PowerShell Functions). I was looking to leverage Microsoft Flow so that I could have them handy as ‘Buttons’ in the Microsoft Flow mobile app.

Quite quickly I realized that Microsoft Flow didn’t have the capability to perform some of the automation I required, so I handed that off to an Azure Function. The Azure Function then needed to leverage a Registered AAD Application. That required an Application ID and Secret (or a certificate).  This wasn’t going the way I wanted so I took a step back.

The Goals I was attempting to achieve were;

• A set of Azure Functions that perform small repetitive tasks that can be re-used across multiple Flows
• Separation of permissions associated with function/object orientated Azure Functions

The Constraints I encountered were;

• Microsoft Flow doesn’t currently have Azure Key Vault Actions
• The Flows I was looking to build required functionality that isn’t currently covered by available Actions within Flow

With my goal to have a series of Functions that can be re-used for multiple subscriptions I came up with the following workaround (until Flow has actions for Key Vault or Managed Service Identity).

Current working Workaround/Bodge;

• I created an Azure Function that can be passed Key Vault URI’s for credential and subscription information
  • typically this is the Application ID, Application Secret, Azure Subscription. These are retrieved from Azure Key Vault using Managed Service Identity
  • returns to the Flow the parameters listed above
• Flow calls another Azure Function to perform required tasks
  • that Azure Function can be leveraged for an AAD App in any Subscription as credentials are passed to it

Example Scenario (as shown above);

1. Microsoft Flow triggered using a Flow Button in the mobile application to report on Azure Virtual Machines
2. Flow calls Azure Function (Get-Creds) to get credentials associated with the Flow for the environment being reported on
3. Managed Service Identity used from Azure Function to obtain credentials from Azure Key Vault
   • Application ID, Application Secret and Azure Subscription returned to Flow
4. Flow calls Azure Function (Get-VM-Status) that authenticates to Azure AD based of credentials and subscription passed to it
5. Azure Resource Group(s) and VM’s queried from the Function App with the details returned to Flow

Concerns/thoughts;

1. Passing credentials between integration elements isn’t the best idea
   • obfuscation is that best that can be done for now
   • having the information stored in three different secrets means all information isn’t sent in one call
     • but three web requests are required to get the necessary creds
2. A certificate for AAD App Authentication would reduce the Key Vault calls to one
   • would this be considered better or worse?
3. At least the credentials aren’t at rest anywhere other than in the Key Vault.

Summary

We’ve come a long way in a year. Previously we just had Application Settings in Azure Functions and we were obfuscating credentials stored their using encryption techniques. Now with Managed Service Identity and Azure Key Vault we have Function sorted. Leveraging modular Azure Functions to perform actions not possible in Flow though still seems like a gap. How are you approaching such integration?