Enabling the Logic Apps PowerShell Connector for performing Azure tasks
This is a fairly short post, but in my last post about deploying a Logic Apps Standard using Managed Identity and private networking, I'd mentioned the customer needed to run some automation tasks. Some of these tasks pertained to maintenance within their application, but some were cleaning up unused resources in Azure, specifically removing stale containers in blob storage. However, when trying to run the Remove-AzStorageContainer PowerShell cmdlet, we got the following error: "The term 'Remove-AzStorageContainer' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again." By default, the PowerShell Connector in Logic Apps does not include the Az PowerShell module. To enable this (or other PowerShell modules you want to use): Open Kudu and open a CMD or PowerShell console Navigate to site/wwwroot Open the host.json file and ensure that you see a property "managedDependency":{"enabled":true} (this is the default and should be present). Open the requirements.psd1 file and add any PowerShell modules and version you want installed, e.g. 'Az' = '12.*' Save the file and restart the web service After that, you can add the Execute PowerShell Code connector. To use a Managed Identity as the user context for performing tasks in Azure, add the following line at the beginning of your script: Connect-AzAccount -Identity -Environment AzureUSGovernment Enjoy!Deploying Logic Apps Standard with Managed Identity and private networking
I was working with a customer who needed to implement some automation tasks to support their application. The automation tasks would be driven on data in their Azure SQL database. As most of their developers were busy tackling their backlog, I thought "What if we could use Logic Apps to do a no code solution with their operations team?" The first step was of course to deploy the Logic App. As the customer is running fully private networking for all services (Azure SQL, Storage, etc.), we would deploy Logic Apps Standard, which runs on the Azure App Service runtime similar to Function Apps. Like a Function App, the Logic App uses a storage account in the background. However, when deploying through the portal, the deployment failed with a 403 Unauthorized error. Of course! The customer had disabled shared key access to storage accounts, utilizing Entra ID exclusively. Like our post about setting up an Azure Container Instance to use Managed Identity to connect to an Azure Container Registry, we'd have to write a bit of Bicep script to utilize a User Assigned Managed Identity which has rights to Azure Storage and SQL. I created the User Assigned Managed Identity and granted it the following roles on the storage account: Storage Account Contributor Storage Blob Data Contributor Storage Queue Data Contributor Storage Table Data Contributor While that solved the access issue and allowed the deployment to complete, the Logic App was showing a runtime error in the portal, stating that it was "Unable to load the proper Managed Identity." As it turns out, we need to explicitly tell the Logic App in the App Service configuration that we are using Managed Identity as our authentication mechanism, and which Managed Identity we want to use. Once I added that to the configuration, my Managed Identity error went away, but I was still getting a runtime error. Looking in the log stream, I could see that I was getting many errors trying to talk to the storage account queue and table endpoints. Because the client is using all private networking, we needed to setup a private endpoint and associated private DNS entry for all three storage account endpoints: blob, queue and table. Once I added those private endpoints and added them to my App Service configuration, my Logic App deployed and ran successfully. I've added the Bicep code for the Logic App service here. One final "Gotcha": if you look in my Bicep, you will note that I am specifying both the User Assigned Managed Identity as well as a System Assigned Managed Identity. The reason for this is, when using a SQL connector, Managed Identity was not listed as an option for authentication. I was stumped by this at first, but then I noticed that it was an option in a portal deployed Logic App. The difference was that the portal deployment adds a System Assigned Managed Identity. Once I added this to my Bicep, the Managed Identity option showed up on the SQL connector. It appears that the connector is looking for the presence of a System Assigned Managed Identity to toggle that authentication option, but you can still use your User Assinged Managed Identity for SQL authentication.
