Manage NSG association on Subnets via Azure Policy
In this blog article, we will cover how to deny the creation of a subnet in a Virtual Network if the subnet does not have a Network Security Group associated with it, using a custom Azure Policy.
You can follow the steps below to create a custom policy:
1) From the Azure portal, access Azure policy, then definitions blade.
2) Create a new policy definition.
3) Add the definition location (which subscription will be hosting this policy), Name, and description.
4) Set the category to use existing and select Networking (as below):
5) Then add the below policy definition into the rule field:
Note: you can adjust the below parameters as needed, also the below example excludes the following subnets. You can add more subnets of your choice.
"GatewaySubnet",
"AzureFirewallSubnet",
"AzureBastionSubnet",
"AzureFirewallManagementSubnet"
6) Then save the policy.
Now you can assign this policy as per your requirements.
1) From Azure policies page, and access definitions blade -> select the created custom policy, and click assign policy (you can assign on the Subscription level or a specific resource group depending on your business requirements).
2) To update the excluded subnet list at time of policy assignment. Go to Parameters tab, then uncheck the box "Only show parameters that need input or review" and select of the three dots next to the "Excluded subnets" box.
3) It will open the editor; update the subnet name you want to exclude and click save.
4) Click Next, and Next, update the "Non-compliance message" as per your requirement.
5) Click review + create and review the output. Once verified create the policy assignment. Policy assignment usually takes around 5-15 minutes to take effect.
To update the list of excluded subnets after the policy assignment.
1) From the Azure portal, access Azure policy, then Assignments blade and search the assignment.
2) Open the assignment by clicking on the name
3) Select Edit assignment
4) Go to Parameters tab, then uncheck the box "Only show parameters that need input or review" and select of the three dots next to the "Excluded subnets" box.
5) It will open the editor; update the subnet name you want to exclude and click save.
Disclaimer
- Please note that products and options presented in this article are subject to change. This article reflects custom policy for Azure Subnets in September 2024.
- If users have the required permissions, they can create exemptions for their resources, which makes this policy ineffective for those resources.
- Some subnets managed by Azure services may not require an NSG. Ensure these subnets are added to the excluded subnet list or use a policy exception as needed.
- It is highly recommended to test this policy in a non-production environment before applying it to your production environment to avoid any unintended disruptions and to make sure it meets your requirements.
References
Tutorial: Create a custom policy definition - Azure Policy | Microsoft Learn
Programmatically create policies - Azure Policy | Microsoft Learn
Troubleshoot common errors - Azure Policy | Microsoft Learn
Overview of Azure Policy - Azure Policy | Microsoft Learn
Published on:
Learn moreRelated posts
Azurite: Build Azure Queues and Functions Locally with C#
Lets say you are a beginner Microsoft Azure developer and you want to : Normally, these tasks require an Azure Subscription. But what if I tol...
Data encryption with customer-managed key (CMK) for Azure Cosmos DB for MongoDB vCore
Built-in security for every configuration Azure Cosmos DB for MongoDB vCore is designed with security as a foundational principle. Regardless ...
Azure Developer CLI: From Dev to Prod with Azure DevOps Pipelines
Building on our previous post about implementing dev-to-prod promotion with GitHub Actions, this follow-up demonstrates the same “build ...
Azure DevOps OAuth Client Secrets Now Shown Only Once
We’re making an important change to how Azure DevOps displays OAuth client secrets to align with industry best practices and improve our overa...
Azure Managed Instance for Apache Cassandra v5.0 Generally Available!
Azure Managed Instance for Apache Cassandra Upgrade to Cassandra v5.0 is now generally available, bringing a host of powerful new features and...
Hunting Living Secrets: Secret Validity Checks Arrive in GitHub Advanced Security for Azure DevOps
If you’ve ever waded through a swamp of secret scanning alerts wondering, “Which of these are actually dangerous right now?”— this enhancement...
Real-Time Security with Continuous Access Evaluation (CAE) comes to Azure DevOps
We’re thrilled to announce that Continuous Access Evaluation (CAE) is now supported on Azure DevOps, bringing a new level of near real-time se...