Convert Azure Firewall to Firewall Manager – part 2

In our previous part, the Firewall policy was created. In this part we will take the policy, do a few minor changes and convert the Firewall we got our framework from.

To start of, the Firewall Policy in itself will not do “anything” until it is applied to Azure Firewall resource (or Secured hub, that is Azure Firewall inside Virtual WAN). The Azure Firewall Policy created can be applied to new Firewall or converting existing firewalls. For this particular case, converting existing Azure Firewall is the target.

Before converting, if we already have another Firewall Policy we want to have as a parent to our current policy, we can proceed to add that to the Azure Firewall policy before. Either we can do this Portal, or handle it via code. Open up the ARM template in VS code and under  “Microsoft.Network/firewallPolicies” resource, under properties, add the following line. Example code

{
    "$schema": "https://schema.management.azure.com/
schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
"parameters":{
..
   "basepolicy": {
            "type": "string",
            "defaultValue": "resourceid"
        }
...
},
"variables:{},
"resources":[
      ..
      "basePolicy": {
                    "id": "[parameters('basepolicy')]"
                }
        ...
        ]
        }
    ]
}

Go live

Converting an existing Azure Firewall to Firewall Manager is none-disruptive operation. How this fit in your change regim, may differ since Azure Firewall more often then not is a central component in your deployment and because of that requires a change window. However from a technical standpoint, there is no traffic lost in the network tests I done during the convert.

To convert a current Azure Firewall can either be done thru the Portal and follow the guide

If you already have Azure Firewall handled via code, it is three things we need to do (ARM template as example).

  1. Remove all current Azure Firewall rules in the ARM template
  2. Remove threatIntelMode setting
  3. Add the Firewall Policy (the one we converted) resourceID reference

"firewallPolicy": {             
     "id": "resourceIDofFirewallPolicy"         
}

Now, the configuration is ready for deployment. If there is an already pipeline, use that. In this example case, we deploy via Powershell

New-AzResourceGroupDeployment -Name "1" -ResourceGroupName´ "firewall-rg" -Mode Incremental -TemplateFile´
.\firewall.json -TemplateParameterFile´
.\firewall.parameters.json -Verbose

The convert usually takes the same amount of time as an regular Azure Firewall rule update. One thing noted is that if you have IP groups as reference, it usually take a bit more time.

After deployment is complete, we can see the difference in two parts in the Azure Portal. On the Firewall object itself we see a difference that we have fewer options on Settings

The settings are now moved to the Firewall Manager, where we can see it under “Hub virtual networks”

Deploy Azure Bastion centrally in Hub & Spoke

Azure Bastion Host is used for remote access of virtual machines without need exposing thoose virtual machines with public IPs. When launched Azure Bastion Host came with a serious drawback, as it did not support VNET peering, hence, we needed to deploy per Virtual Network, making the solution expensive as you needed one per spoke.

Luckily, Azure Bastion Host now has support for VNET peering. Hence the requirement to have one Azure Bastion host per virtual network is not required anymore to get it to work. The next logical placement of the Azure Bastion Host is now to put it more centrally, to keep one Azure Bastion host per region deployment, thus saving cost. A common place can be the connection hub vnet, since it is a well connected with the spokes. If that is the case, you do not want to give more access then needed, since there is other important resources in that subscription. All needed permissions for the Azure Bastion Host can be read at the FAQ for BastionHost for VNET Peering.

Implementation
First part is to establish a role defination as there is no role for Bastion Host as for this date. Hence we need to create a custom role defination. Here is deployment template for BastionReader.
Important to note, in case you do not have access to the root management group, you will need to modify it to a scope where you have the permissions to add Role definitions.

Second part is to deploy the actual Azure Bastion host resource and allocate an group to that role defination. Template for that can be found here.

The input parameters are

  • Basename, prefix for the resources
  • VirtualnetworkID, this is the ID to the virtual network with the AzureBastionSubnet
  • Role defination ID, the ID of the Bastion Reader
  • AAD group, the object ID of the group that will have access to the Bastion resource

After the template is deployed, we are now ready to use the Azure Bastion Host. When using it, make sure that subscription filter is not filtering out the subscription where you are Azure Bastion Host is located, since it utilize this for lookup.

Conclussion
From an architectual this is not an optimal solution, since you do not want to give permissions in the your hub subscription to “everyone” if not needed. Hopefully there is some clever solutions from Microsoft coming to change this.