Prevent Assignment of Reserved CIDRs to Subnets

[MrCaedes]

Overview

This PR introduces a new Azure Policy definition as part of /Network.

The policy enables for CIDRs to be configured as non-usable by subnets; this can be useful in self-governing teams where a large range is allocated - but wish to earmark portions for specific purposes, such as future expansion, shared services, etc.

Problem Statement

In enterprise environments with decentralized subscription ownership, teams often receive large IP address allocations to manage independently. Without guardrails, there's a risk that subnets could inadvertently consume IP ranges earmarked for,

• Shared Services (e.g., if the team is offering a service to others)
• Future Growth (e.g., planned expansions of AKS, etc)

What the Policy Does

This policy uses ipRangeContains to perform bi-directional overlap detection.

The intent is for this to be used in combination with "Exemptions", to provide just-in-time provisioning ability - whilst providing a hard guardrail.

If Azure Policy becomes identity-aware in the future, there is also scope for this to be used such that only X user may leverage specific ranges - useful in platform-team scenarios.

[gregslack78]

Going to test this one and put it through the policy authoring agent.

[gregslack78]

Policy authoring agent output...

Evaluation:
Correctness:
The logic for detecting overlap uses Azure's built-in ipRangeContains function to ensure checks are done against both the CIDR ranges and the subnets.
Functionality:
This policy should work as intended, evaluating virtual networks and subnets for compliance with the restricted CIDR ranges provided.
Conclusion:
The policy should effectively enforce limits on CIDR overlap, with a configurable effect to either audit or deny infractions. It should operate properly in Azure environments as long as the defined logic matches the expected compliance rules.

[gregslack78]

Started testing this.

1. I am unable to copy and paste this policy in to the portal. When I do it does not allow me to save the policy because there is this warning (String does not match the pattern of "^[(parameters)('.+').*]$".) on every line that has "value": "[parameters('restrictedCIDRs')]",

2. I was able to get around this by deploying with EPAC. After deploying with EPAC the policy is editable.

3. I can also duplicate the definition in the portal to put it in a different location and that is savable.

4. Policy is assignable.

5. Verified if you create a VNet within a restricted CIDR and take the default subnet the VNet creation will be prevented. If you remove the default subnet VNet is created.

6. FAILED - After created the subnetless VNet in the restricted CIDR and attempting subnet creation, the subnet was successfully deployed. I assume this is because when you create the subnet after the VNet creation the resource being created is Microsoft.Network/virtualNetworks/subnets and the policy is only looking for API calls to Microsoft.Network/virtualNetworks. This also means it would only work with IAC if you were managing subnets like this...

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
name: 'vnet1'
properties: {
subnets: [
{
name: 'subnet1'
properties: {
addressPrefix: '10.0.0.0/24'
}
}
]
}

But not like this....

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-05-01' = {
name: 'vnet1/subnet1'
properties: {
addressPrefix: '10.0.1.0/24'
}
}

The solution may be to try some like this at the start of the rule.... (will test this tomorrow)

"policyRule": {
  "if": {
    "anyOf": [
      {
        "allOf": [
          {
            "anyOf": [
              {
                "field": "type",
                "equals": "Microsoft.Network/virtualNetworks"
              },
              {
                "field": "type",
                "equals": "Microsoft.Network/virtualNetworks/subnets"
              }
            ]
          },