In many Azure environments, Network is core to the solution. As such, it is one of the most critical components to design correctly and with the required configuration relative to posture and security.
For example, you create a well architected network, with a focus on security and performance. It works well, but then changes occur outside of your original design – and it starts to come apart.
Azure Policy is one solution to ensure that this does not happen. For this specific topic, Azure Policy will focus on two areas:
- Enforce standards
- Systematically assess compliance
It can also action remediation using DINE or deploy-if-not-exists policies. That may be your preference, but for me that’s not something I like at the network layer 🙂
So first, my preference is to create a core policy set, derived from your core network design. On Azure Policy, this will be policy definitions grouped as an initiative. Where possible, it is efficient to use existing built-in definitions. However, if required you can create custom definitions and also include them in your initiative.
For this post, I have created a simple example initiative that includes several built-in policies based on some network and security requirements for an app architecture.
Within this set, you can see “Not allowed resource types”, in here I have included several public or connection focussed resources such as:
- Public IP addresses
- VNET Peerings
- Local Network Gateways
The idea behind the above aligns with the purpose of Azure Policy, restrict and define the platform. This core initiative obviously has a focus on network type resources, but the same basic principal applies. Similar again in approach is the ability to allow exclusions where necessary. For example, allowing VNET peering in a network resource group. However, don’t forget/ignore RBAC, this should at minimum compliment your policy requirements.
While this example is quite simple, as I mentioned, you can layer complexity in via custom policies (creation tutorial here). One I have always liked is a policy to ensure that your subnets have the appropriate Route Table applied to ensure traffic is being directed appropriately, for example, to a firewall. The linked example is just an audit for subnets without ANY route table, but you can expand on this to include a specific route table.
{
"properties": {
"displayName": "AINE Route Table for subnets in vnets",
"policyType": "Custom",
"mode": "All",
"description": "Custom policy to audit if a route table exists on appropriate subnets in all vnets",
"metadata": {
"version": "1.1.0",
"category": "Network"
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/virtualNetworks/subnets"
},
{
"field": "name",
"notEquals": "AzureBastionSubnet"
},
{
"field": "Microsoft.Network/virtualNetworks/subnets/routeTable.id",
"exists": false
}
]
},
"then": {
"effect": "audit"
}
}
}
}
The above is stored on a repo in Github for you to re-use if needed, and don’t forget if you are using VS code to install the Azure Policy extension to make life a bit simpler!
wedoAzure 