Configuration / Management of Existing Virtual Networks

As part of a Project Set, a Virtual Network (VNet) is created for use. However, no Subnets are created, as this is delegated to the respective User team to control based on their needs.

The current challenge with the Azure Landing Zones approach, is that several Azure Policies are deployed at a higher level, and require subnets to have a Network Security Group (NSG) and a User Defined Route (UDR) associated with them.

Because of limitations with the Azure APIs, using a "normal" approach to create a subnet and associate an NSG/UDR, fails because the subnet is first created, then the association to the NSG/UDR is made. But, the Azure Policy blocks the creation of the subnet, because it doesn't have an NSG/USR associated.

A community-based Terraform module (terraform-azurerm-alz-subnet) has been created to work around this conflict, using the AzAPI provider.

We need to test using this module, if it meets our user's needs/requirements, so that we can provide a recommended approach and guidance post-onboarding into their respective Landing Zone/Project Set.

Acceptance Criteria

[ ] Scenario: Testing the compatibility of the Terraform module with Azure Policies
- Given the Terraform module is implemented
- When using the module in a Landing Zone with existing Azure Policies
- Then the subnet creation should not be blocked by the policies, and the NSG/UDR associations should still be made automatically

A working example can be found in the ecf-azure-startup-sample-app-serverless repo (though may be moved to a common repo in the future.

The current code example (located in the infrastructure/application_networking/ directory) includes:

Creating a Network Security Group (NSG) for each subnet, using the subnet name as the NSG name
Creates the subnet with the assigned address prefix
Adding subnet delegations (if specified)
Adding service endpoints (if specific)
Enabling private endpoint network policies (if specified)
Associating the Network Security Group (NSG) created with the subnet

How-To Use this Module

To use this module, you need to provide the following information:

virtual_network_name
virtual_network_resource_group

This is used to look up information about an existing Virtual Network (VNet).

TFVars Example:

virtual_network_name           = "e833c2-dev-vwan-spoke"
virtual_network_resource_group = "e833c2-dev-networking"

Additionally, to create new subnets within the existing Virtual Network (VNet), you need to provide a map in the following format.

[!NOTE] Only the subnet_name and address_prefixes properties required, all other properties are optional.

TFVars Example:

virtual_network_subnets = {
  frontend = {
    subnet_name      = "frontend"
    address_prefixes = ["10.41.8.0/26"]
    service_endpoint_names = [
      "Microsoft.Web",
      "Microsoft.Storage"
    ]
  }
  middle = {
    subnet_name             = "middle"
    address_prefixes        = ["10.41.8.64/26"]
    delegation_service_name = "Microsoft.Web/serverFarms"
  }
  backend = {
    subnet_name                               = "backend"
    address_prefixes                          = ["10.41.8.128/27"]
    private_endpoint_network_policies_enabled = true
  }
}

Challenges / Limitations

The current implementation of the vWAN spoke, creates a Resource Group to contain the VNet resource. This Resource Group has a Delete Lock enabled on it, to protect against accidental deletion.

While this is considered a best-practice approach, it will prevent the deletion of the subnets when using terraform destroy. The Delete Lock would have to be temporarily removed, and then re-added.

bcgov / Cloud-Pathfinder-Azure