Retrieving Key Vault Secrets from a Logic App using Managed Service Identity

Azure Logic Apps are great for automating tasks, and there is a plethora of actions available out of the box. However, sometimes these don’t work the way you would like, so it comes down to failing back to the old tried-and-true methods. I recently came across this with Azure Key Vaults.

For the uninitiated, Azure Key Vaults are security enclaves deployed within Azure data centers that are used for the sole purpose of key and secret storage. This allows the escrow of these sensitive pieces of information in dedicated hardware, which can only be retrieved by an account with the proper permissions. These Key Vaults are also ridiculously inexpensive, costing only $0.03/1000 operations (for standard Key Vaults) which makes them a no-brainer for usage.

Out of the box, Azure Logic Apps do have integration with Azure Key Vaults via an action (currently in preview at the time of writing). However, this integration only offers two means of authenticating to the Key Vault:

  • Creating a connection using a named user
  • Authentication via a pre-created Service Principal
Azure Key Vault Actions

These options have a major downfall: the management of a password or secret for connectivity. By signing in with my account (or a service account), that means that if I or that account are ever offboarded, this connection is broken and must be reestablished. Service Principals can help mitigate this, but the secret that’s used must be managed, or set to never expire (which I prefer not to do as a security hole).

The fix: Managed Identities!

Managed Identities in Azure AD are like (group) Managed Service Accounts (gMSAs) in Active Directory: The principal is created and a randomly-generated password is used and managed by Azure AD. This significantly reduces the attack surface of this account, as the password is never exposed to anyone, and the lifecycle of the identity (for system-managed) is tied to the resource: when it is deleted, the Managed Identity is removed as well. Managed Identities can be used with many different Azure resources, including Virtual Machines, and in our case, Logic Apps!

Creating the Managed Identity

Creating the Managed Identity is extremely simple. Within the Logic App, simply navigate to the Identity area of the Logic App blade, and switch the Status to On. This will automatically create the identity in Azure AD and provision all the backend items.

Once this configuration is saved, the Object ID will be displayed and the object can be found in Azure AD using the name of the Logic App or the Object ID.

Created Managed Identity
Managed Identity in Azure AD

Phew, that was difficult! Now we can assign that Managed Identity rights to our resources.

Assigning the Managed Identity Within Azure Key Vault

Once our Managed Identity is created, we can assign it to secrets in the Key Vault. I’m going to create a secret for our purposes for this Logic App.

The first step is to create the secret, which is no different than normal in a Key Vault. Navigate to the Key Vault, select Secrets, and add a new Secret.

Azure Key Vault Secret Creation 1
Azure Key Vault Secret Creation 2

Once the secret is created, we can set our Access Policy in the Key Vault. Note down the URI of this Secret, we will need this later.

First we navigate to Access Policies and Add New

Key Vault Access Policies

In the Access Policy, we select our Managed Identity and give it permissions to read Secrets.

Selecting our Managed Identity
Setting the appropriate permissions

Our Managed Identity can now retrieve Secrets from this Key Vault. Now comes the fun part where we use it in a Logic App

Using Stored Secrets in a Logic App

Now we can put it all together.

Within the Logic App, instead of using the Key Vault action to retrieve Secrets, we will instead use an HTTP request. We will use the following parameters:

  • Method: GET
  • URI: <Key Vault Secret URI>
  • Queries: api-version=7.0
  • Authentication: Managed Identity
  • Audience: (This is accessible via the Add New Parameter dropdown)
Retrieving our Secret

By running this manually, we now see that the Secret is returned:

Returned Secret

Now I can send this to a simple Parse JSON activity to extract the secret, which can then be used in later activities.

Parse JSON and use in HTTP call

And that’s it! I’ve now retrieved a Secret from an Azure Key Vault using a Managed Identity!

Push MDATP Alerts to Log Analytics using Logic Apps

One of the questions that I get asked all the time is how to integrate cloud solutions into monitoring platforms. Whether it is Azure AD sign-in logs, Exchange Audit Logs, or anything else, the primary desire is a centralized location for these logs to provide a “single pane of glass”.

In the past, Rich and myself have talked with clients about using Azure Log Analytics as the centralized platform. However, it was never really a SIEM, and many clients wanted to keep using their on-premises solutions, such as Splunk, ArcSight, or similar.

With the addition of Azure Sentinel on top of Azure Log Analytics, we’re starting to have more conversations about leveraging cloud-native solutions instead of bolted-on products. Because of the work we do in the Microsoft security space, one of the items we wanted to do was push data from Microsoft Defender ATP (formerly Windows Defender ATP) into Log Analytics, which we can then write queries and alerts on within Sentinel.

To do this, we decided to use Azure Logic Apps for two main reasons:

  1. It is low-cost, with a consumption-based model
  2. It provides a modular, graphical means of authoring workflow

This Logic App consists of five easy steps.

Step 1: The Trigger


All Logic Apps must start with a trigger, either based on an event or a schedule. We decided to start this Logic App off simply: a trigger based on when a Defender ATP Alert occurred. Pretty simple, and we just used Rich’s account for the API integration.

Logic App Trigger

Step 2: API Call, The First

The first real step after receiving data via the trigger is to… Receive data.


To push data into Log Analytics and have it parsed properly, we want to submit each alert (and corresponding information) as a single JSON object to the Log Analytics endpoint. However, the output from the trigger is just the alert ID and machine ID. We could send that into the activity specifically used for the retrieval of alerts that is built in to Logic Apps, but that gives us a nicely parsed object, which isn’t what we want.

To fix this, the first step we are doing is to pull the alert directly from the MDATP API, which does give us our JSON object. To do this, we have created an App Registration in Azure AD to handle this connection for us. We are using the following configuration:

  • Method: GET
  • URI:<Alert ID from Step 1>
  • Authentication: Active Directory OAuth
  • Tenant: <AAD Tenant GUID>
  • Audience:
    • Note the lack of a trailing “/” at the end
  • Client ID: <App Registration Client ID>
  • Credential Type: Secret
  • Secret: <App Registration Key>
First API Call

Step 3: API Call, The Second

Because alert info isn’t everything we need, we also decided to pull in machine information for a given alert. Luckily, this configuration is nearly identical to the other API call, just a different endpoint. For this, we’re using the following settings. Stop me if this looks familiar:

  • Method: GET
  • URI:<Machine ID from Step 1>
  • Authentication: Active Directory OAuth
  • Tenant: <AAD Tenant GUID>
  • Audience:
    • Note the lack of a trailing “/” at the end
  • Client ID: <App Registration Client ID>
  • Credential Type: Secret
  • Secret: <App Registration Key>
Second API Call

Step 4: Putting it All Together

Now that we have all of our data, we can push it into ALA. However, we want to ensure that the two items are linked, and we don’t want to maintain multiple tables. So to fix this, we’re simply joining both JSON objects into a single one using the union() function in Logic Apps. Luckily, we aren’t sharing many fields between the two objects, so we don’t have to worry about overwriting properties. This is then utilized by the in-box action to send data to Log Analytics, into a custom log we’ve named MDATPAlerts. Note: Log names in Log Analytics are case sensitive, so if you are creating multiple Logic Apps to forward data, our MDATPAlerts log would be different from a MDATPalerts log.

Sending data to Log Analytics

The Final Product

In the end, we now have all MDATP alerts going into our workspace, which we can generate alerts on in Sentinel, create dashboards, and correlate against other potential IoCs. All these logs are going into our MDATPAlerts_CL log (CL meaning Custom Log) in Log Analytics, and can be searched from there. Then the fun begins!