"Network Security Group doesn't have supporting Security Rule for Network Intent Policy Security Rule"
If you’re trying to deploy Azure SQL Managed Instance in Azure via Azure Bicep you may have stumbled across this ‘Network Intent Policy’ error when trying to redeploy your Azure Bicep template.
The problem doesn’t present itself on your first deployment yet when trying your template again this error is present. It seems if we don’t define the network security group rules and routes for the SQL Managed Instance network intent explicitly in our Bicep template then ARM believes something is either changing or being redeployed. To me, this goes against the idempotent nature of ARM/Bicep to a degree.
At the time, I was referencing the CARML modules for Azure SQL Managed Instance for what I should include in my template, which did have some rules defined around network intent policy rules. However, these were not working for me. I later discovered the rules defined were the pre November 2022 mandatory rules and so not valid for my deployment.
In my searches I could not find any off the shelf Bicep code for the current rules, so I decided to put something together in hope it helps others get around the error quicker than I did.
What is the network intent policy?
In order for Azure SQL Managed Instance to function correctly, it needs certain rules and routes defined and those rules must remain in place. Microsoft state:
“To improve service security, manageability, and availability, SQL Managed Instance applies a network intent policy on some elements of the Azure virtual network infrastructure. The policy configures the subnet, the associated network security group, and the route table to ensure that the minimum requirements for SQL Managed Instance are met. “
The fix to make your Azure Bicep templates idempotent
In order to fix the network intent policy error and have a Bicep template that can be redeployed over and over again we must define the network intent policy rules in the Bicep template after initial deployment.
Here is the current NSG security rules & route table routes for Azure SQL Managed Instance with Bicep that I’ve put together. Built from the following Azure SQL Managed Instance connectivity table here.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
// SQL MI NSG and Route table with mandatory subnet service-aided config: https://learn.microsoft.com/en-gb/azure/azure-sql/managed-instance/connectivity-architecture-overview?view=azuresql&tabs=current#mandatory-security-rules-with-service-aided-subnet-configuration
//
// where modules defined are copied locally from CARML/Azure Verified Modules GitHub Repositories. https://github.com/Azure/ResourceModules/tree/main/modules/network/network-security-group & https://github.com/Azure/ResourceModules/tree/main/modules/network/route-table
//
//
// Azure Bicep with complete list of current Azure SQL MI mandatory security rules & routes for repeatable template deployments without template violations
// Insert this to your Azure SQL MI Bicep templates to avoid Network Intent Policy errors when redeploying Bicep templates for Azure SQL MI and avoid erorrs like: https://github.com/Azure/azure-quickstart-templates/issues/6670
@description('Enter Azure SQL MI subnet address prefix.')
param subnetPrefix string = '10.1.2.0/24'
var subnetPrefixString = replace(replace(subnetPrefix, '.', '-'), '/', '-')
These networking objects have been created based on what the current architecture requires for the security rules & routes, which sets out the mandatory rules and routes required for Azure SQL Managed Instance to work properly.
Alternatively, after the initial Azure SQL Managed Instance deployment, go to your Network Security Group and Route table, export to template and convert to Bicep using the decompile command (or if you have the VSCode extension, it should auto-convert on paste!): az bicep decompile --file main.json
What’s your thoughts?
Hopefully this saves others some time when trying to create their Azure Bicep SQL Managed Instance templates! There is a GitHub issue open which seems like others are hitting the same hurdle too:
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Latest Posts
APIOps – A deep dive for APIM multi-environments
Never miss an update: Azure Verified Modules with GitHub Bot & Teams
Getting started: Continuous deployment with Azure Bicep and Azure DevOps