SITEMAP
Introduction
I am going to show you (based on a sample application) how to create an Azure Logic App that talks to Azure Key Vault, Azure Storage Account, and Aviatrix Controller.
The topic is divided into two parts:
- Part 1: this article, presents the task, algorithm, and components used
- Part 2: presents the real implementation of the Logic App ( https://cloud-cod.com/index.php/2024/03/14/azure-logic-app-talking-to-storage-account-key-vault-and-aviatrix-controller-part-2/ )
Environment and Task
Let me present you my Azure environment and the task that we want to achieve.
My test environment consists of 2 Aviatrix Transit Gateways: az-10-120-tgw and az-10-130-tgw. Those Transit Gateways have some VPN connections (Site-to-Cloud tunnels) created:
- conn120-1 terminated on az-10-120-tgw
- conn130-1 and conn130-2 terminated on az-10-130-tgw
Please keep in mind that the number of Aviatrix Transit Gateways and VPN connections is not relevant. I have created a small number of them just to show you how the Logic App is going to work.
What is important though, is that both Aviatrix Transit Gateways have BGP Route Approval feature enabled (more: https://docs.aviatrix.com/documentation/latest/building-your-network/transit-bgp-route-approval.html?expand=true).
The Gateway az-120-tgw is using Route Approval in Gateway Mode. Whereas, az-130-tgw is using the feature in Connection Mode.
The goal is to be notified whenever the number of approved CIDRs changes. There are different ways how we could do it. The Logic App is going to execute some API calls to the Aviatrix Controller to get the information about Route Approval feature for both Transit Gateways. I will just keep track of the number of approved CIDRs and not the CIDRs themselves (though the approach would be the same in the latter case).
What components/services do we need?
- Aviatrix Controller (obviously)
- Azure Key Vault – Secrets that store our Aviatrix Controller domain name, user, and password (we need them for API calls)
- Azure Storage Account – to store the following:
- the list of Aviatrix Transit Gateways that we want to examine
- the details Route Approval information (per Gateway)
- the total number of approved CIDRs (per Connection or per Gateway depending on the Route Approval Mode)
Algorithm of application
Before jumping in into the application itself, I am going to present the high-level algorithm of how the application is going to work.
Important parts:
- The application starts with Logic App Variables initialization
- all the Logic App Variables must be initialized before they can be used
- Next step is to execute an API Call to Aviatrix Controller to get a CID
- it is enough to make a call only once
- Once the CID is retrieved we will fetch the information about Route Approval for every Gateway from the list of Gateways
- this is where we need a for-each loop
- the application is going to save all the Route Approval information received from the Controller in the Azure Storage Account Blob
- the application determines whether the Route Approval Mode enabled on the Gateway is Connection or Gateway type
- Condition (true/false) is needed here
- for Gateway Mode (“right leg” of the Condition)
- it is enough to execute this part once for every Gateway (with Route Approval Gateway Mode)
- the previous number of approved CIDRs is compared to the current number
- if the number of approved CIDRs is different (previous vs current) the new value is stored and notification is triggered (e-mail or MS Teams Adaptive Card)
- for Connection Mode (“left leg” of the Condition)
- it could happen that there are more than just 1 connections configured on a specific Transit Gateway
- the application must check every connection
- this is where we need another for-each loop
- likewise the Gateway Mode, the previous number of approved CIDRs is compared to the current number
- if the number of approved CIDRs is different (previous vs current) the new value is stored and notification is triggered (e-mail or MS Teams Adaptive Card)
Storing the Data
As you have probably noticed, I mentioned already few times Azure Blob Storage. Why is it required? The application is going to retrieve some pieces of information from Blob but also it is going to store some other important data. Let’s have a look at how and what kind of Blobs are going to be used.
The following files are required to be created before the application runs:
- gw_list.txt – it contains a list with Transit Gateway names that we want to check
- for Connection Mode Gateways: there is one file created for every single connection. Those files store the total number of Approved CIDRs. Every execution of the Logic App overwrites the existing file. The name of the files is: <transit-gw-name>-<connection-name>.txt
- for Gateway Mode Gateways: there is only one file created per Gateway. Those files store the total number of Approved CIDRs. Every execution of the Logic App overwrites the existing file. The name of the file is: <transit-gw-name>.txt
The application itself creates the following files:
- for every single Gateway: there is a file created with all the information gathered by API Call “Show Transit Learned CIDRs Approval Info”. Please notice that the name of the file contains a timestamp. It means that every execution of the Logic App will create a new file (the existing files are not overwritten). The name of the file: <transit-gw-name>-<timestamp>.json
The example below shows the files created in my environment:
Logic App Implementation
The implementation of the Logic App is presented in the Part 2 blog article: https://cloud-cod.com/index.php/2024/03/14/azure-logic-app-talking-to-storage-account-key-vault-and-aviatrix-controller-part-2/