ARM: Deploy Logic App with connection configured for Azure Sentinel connector

Azure Sentinel team has developed a great connector for Azure Sentinel, which you can use to automate your Logic App. The Azure Sentinel Connector currently contains the following actions:

In this blog we will focus on how to deploy a logic App configured with the correct Connection credentials for the Azure Sentinel connector through ARM template.

When adding the Azure Sentinel trigger step or an action to the logic App, we need to provide a connection which will be used to authenticate the Azure Sentinel environment:

Most of the time this is automatically created  through the Azure Portal, with your current user credentials if you have the right permissions. But that’s not what we are looking for 😛 So the other option is to select “Connect with Service Principal” and provide a Client ID and secret, which will be used to access the Azure Sentinel resource:

Reader permission is enough if you only want to read data. However, if you for example want to use the “Update Accident” action from the Azure Sentinel connector suit, the SPN needs to have higher privilege’s.

Now we know that we can use a Client ID and secret to authenticate, it’s time to create the “Managed API” connection resource with the correct properties. You can achieve this with the configuration below:

So next we need to combine all the configuration and link all the resources together in the ARM template to deploy our solution. Below a simple Logic App, which contains Azure Sentinel trigger step and a “Get Incident” action:

The Logic App must always start with “When a response to an Azure Sentinel alert is triggered” step.

After deploying the above ARM template the resources below will be created:

Here you see how the Azure Sentinel actions in the Logic App are automaticity configured to use the azureSentinel connection:

Infrastructure as Code – Deploy Azure VNet with dynamic subnets

A frequently asked question about rolling out Azure VNet with different subnets in a infrastructure as code environment is where and how to define the subnets in your Azure ARM template. In the most examples online the number of subnets is configured in the template and the name and addressPrefix is configured in the parameter file. The big disadvantage with this scenario is that when you deploy a VNet with for example two subnets and later you decide to add more subnets you have two choices both of which are uncomfortable for an Infrastructure as code release pipeline. Continue reading Infrastructure as Code – Deploy Azure VNet with dynamic subnets