Hands on With Azure Virtual Network Manager

Introduction

The announcement of Azure Virtual Network Manager (AVNM) is just one of the many exciting announcements from Microsoft Ignite 2021. It’s a new service that allows you to centrally manage your virtual networks, topologies and security rules globally. Some of the key features include:

• Manage network topologies (e.g. hub and spoke)
• Configure security rules that take precedence over NSG rules
• Works across subscriptions and regions
• Dynamic selection of VNets to manage

The management of network topologies means you can specify whether you want a hub and spoke or mesh topology. The network manager will configure it for you by setting up all the peerings between any VNet within the network group (more on network groups later).

Image source: Microsoft AVNM Product Page

Configuration of security rules allows you to create sets of security rules (precisely the same format as NSG rules) and apply them at a VNet level. This means they take precedence over all other NSG rules! This is a pretty awesome feature that will be very useful for platform teams managing cloud infrastructure.

Importantly, all of this works across subscriptions and regions. This is a must-have given the environments this service targets and will make managing VNets distributed across subscriptions and regions a lot easier - another win for platform teams the world over!

Finally, AVNM uses this concept of network groups (not to be confused with network security groups), which are just a collection of VNets. What’s cool about them is that they can be dynamic, meaning VNets can automatically become part of a VNet group just by having certain properties such as tags, subscription or resource group. Not having to endure the additional step of adding a new VNet to the network group makes a big difference to the service’s ease of use.

Deploying

Given AVNM is a preview service there is limited support for infrastructure-as-code, so I decided to give Bicep a go here given it has near day-zero support for most new services and features. I deployed a hub VNet, some spokes and the network manager resources to try out the AVNM features. If you’re interested you can get the code here.

First things first, what’s it like to deploy? Super easy. There isn’t much to configure to get the AVNM resource deployed. You’ll need to do a bit more work to make it worthwhile, but deploying the resource can be done easily with only a handful of properties to configure. All we need to set is the features we want to enable and the scopes that the network manager should access. In testing, I turned on both features (how could I resist) and set the scope at a subscription level. The process via the portal is a breeze, and in Bicep, it looks like this:

resource networkManager 'Microsoft.Network/networkManagers@2021-02-01-preview' = {
  name: 'vnm-network-manager'
  location: resourceGroup().location
  properties: {
    networkManagerScopeAccesses: [
      'Connectivity'
      'SecurityAdmin'
    ]
    networkManagerScopes: {
      managementGroups: [
        '/providers/Microsoft.Management/managementGroups/12345678-90ab-cdef-1234-567890abcdef'
      ]
      subscriptions: []
    }
  }
}

The two items under the networkManagerScopeAccesses section are the features we want to enable. Connectivity is for configuring network topologies, and SecurityAdmin is for setting security rules.

Network Groups

Once you have a network manager deployed, the next thing to configure is a network group. This is how you select which VNets configurations are applied to. That selection can be dynamic or static. Dynamic means that any VNet with a certain property (e.g. a tag) is added to the group. Static membership means a VNet has been explicitly added to the group. The cool thing about network groups is that they can span subscriptions and regions, making it much easier to apply a configuration to all desired VNets.

resource networkGroup 'networkGroups' = {
  name: 'spokes'
  properties: {
    conditionalMembership: '''
    {
      "field": "tags['spoke']",
      "exists": true
    }
   '''
  }
}

Connectivity Configurations

With a network group in place, it’s time to get a configuration built. I started with a connectivity configuration to set up a hub and spoke network. This is easy to do in the portal or with Bicep. Choose hub and spoke, pick a hub, add a network group, tick use the hub as a gateway and you’re on your way.

Remember that your hub VNet must have a VNet gateway if it is going to act as a gateway, otherwise the peering will fail. If you’re using the demo Bicep from above it’s included.

I haven’t tried deploying a mesh network with AVNM, so if you give it a go, I’d love to hear about your experience. You can reach me using the icons at the bottom of the page.

resource hubAndSpoke 'connectivityConfigurations' = {
  name: 'hub-and-spoke'
  properties: {
    appliesToGroups: [
      {
        groupConnectivity: 'None'
        isGlobal: 'False'
        networkGroupId: networkGroup.id
        useHubGateway: 'True'
      }
    ]
    connectivityTopology: 'HubAndSpoke'
    hubs: [
      {
        resourceId: hub.id
        resourceType: hub.type
      }
    ]
    isGlobal: 'False'
  }
}

Security Admin Configurations

Security admin configurations allow us to specify network rules that apply to all of the VNets within a network group and take precedence over any rules defined at an NSG level within those VNets. This is pretty powerful and provides a way for platform and network teams a way to efficiently enforce policy across their networks.

Creating one is pretty straightforward, albeit a little nested when doing this in the portal. You start by creating a security admin configuration, then a rule set, then a rule. The new rule blade is very similar to the new rule blade in NSGs, so you’ll be in familiar territory at that point.

The Bicep sample below is pulled from the demo code where it’s nested under the network manager resource itself hence the short type names.

resource allowOnPremPolicy 'securityAdminConfigurations' = {
  name: 'allow-on-prem'
  properties: {
    deleteExistingNSGs: 'True'
    securityType: 'AdminPolicy'
  }

  resource allowOnPremRules 'ruleCollections' = {
    name: 'allow-on-prem'
    properties: {
      appliesToGroups: [
        {
          networkGroupId: networkGroup.id
        }
      ]
    }

    resource allowOnPremIn 'rules' = {
      name: 'allow-on-prem-in'
      kind: 'Custom'
      properties: {
        access: 'Allow'
        direction: 'Inbound'
        priority: 100
        sources: [
          {
            addressPrefix: '0.0.0.0/0'
            addressPrefixType: 'IPPrefix'
          }
        ]
        destinationPortRanges: [
          '3389'
          '22'
          '80'
          '443'
        ]
        protocol: 'Tcp'
      }
    }

    resource allowOnPremOut 'rules' = {
      name: 'sallow-on-prem-out'
      kind: 'Custom'
      properties: {
        access: 'Allow'
        direction: 'Outbound'
        priority: 100
        destinations: [
          {
            addressPrefix: '0.0.0.0/0'
            addressPrefixType: 'IPPrefix'
          }
        ]
        destinationPortRanges: [
          '3389'
          '22'
          '80'
          '443'
        ]
        protocol: 'Tcp'
      }
    }
  }
}

Deploying Configurations

With connectivity and security admin configurations created, we need to deploy them to the regions we want them to apply to. It’s a really simple process; choose the type of configuration you want to deploy (connectivity or security admin), select the configuration(s) you want to deploy and the regions you want to deploy to then hit the deploy button. Until this step is done, the configurations aren’t having any effect.

I wasn’t able to find a way to create the deployments with Bicep; I could only create them in the portal or using PowerShell. However, the service is still in preview, so I hope to see Bicep support when AVNM becomes generally available.

Adding new VNets

I was most curious about this part; what happens when I deploy a new VNet into a region where I have also deployed some AVNM configurations. I was very keen to see if the configuration took effect automatically without any human intervention and how long it took for this to happen.

So the good news is, it definitely works automatically. I created a new VNet with the tag that should mean it is found by the dynamic criteria of the network group, and that worked perfectly. As for how long the process takes, it took roughly 10 minutes - not bad. I also didn’t have to lift a finger for the peering to be implemented other than making sure the VNet was tagged correctly when I created it.

Cleaning up

With AVNM being a new service still in preview, there is bound to be a snag somewhere. For me, this was when I wanted to destroy all my resources from testing. I found that the resource group containing the VNet manager wasn’t deleting, but I also wasn’t getting any error messages. Before deleting the VNet manager you’ll need to make sure:

• No configurations are deployed to any region (the image below shows how to do this)
• All configurations within the network manager have been deleted
• All network groups within the network manager have been deleted

After that I was able to destroy the VNet manager and its resource group without trouble. Basically, make sure your VNet manager doesn’t have any child resources before you try to delete it.

Conclusion

To summarise, Azure Virtual Network Manager is a handy piece of kit for platform teams. It’s one that I can see being adopted to aid in the management of complex enterprise environments. Whether it’s right for your use case will depend on the maturity of your infrastructure as code and governance processes.

Not too many bugs or issues to report here other than the destroy issues I mentioned above. It would be awesome to see the service able to apply routes that take precedence in much the same fashion as security rules. The service is still in preview, so there is still plenty of time for improvements to be made before it becomes generally available.

If you have any thoughts or questions on AVNM please reach out using the icons at the very bottom of the page, I’d love to hear from you!