Azure: Creating a route table in Bicep and addressing linter rule warning

 I was creating a route table in Bicep and using an example from MSFT, see example here.

The example uses the 'contains' function which throws a warning when deploying with a suggestion to simplify the syntax. Below you can see the warning:

The warning links to the Linter rule - use safe access page.

The suggested change can be seen below. It still performs the same function - it checks if the value exists, if it does, it uses it, if not it sets the value to null.

The updated example can be found on Github here (it uses routes for Databricks as an example, but can be replaced with your own routes).

Using Azure Verified Modules (AVM) - Bicep

 In January 2024 Microsoft launched a new initiative called Azure Verified Modules (AVM). It's a collection of official and supported Bicep and Terraform modules that makes it easier to deploy resources in a standardized fashion as-code.

It's easy to use and fast to get started. And I was actually surprised at how well it works. One of the reasons for this initiative is that until now there hasn't been a formal, centralized repository for modules or templates so people have been relying on either there own or some public repo that might not be maintained over time.

The link for AVM is: http://aka.ms/avm

And the getting started guide (which is quite good) is here: http://aka.ms/avm/using

You should have VS Code installed and the Bicep extension. And Azure CLI, see install info here for Windows or here for MacOS.

And then you just follow the guide.

To use the modules you have to have internet connection from your source. If not, you can download a local copy of all the content and reference them locally.

For each resource module there is a basic version and an extended version with more options. You can copy the additional parameters from the extended version into the basic version or start with the extended version and remove the parts you don't need.

The good thing about modules is that most of the code (or the Bicep file) is managed/written by MSFT and you only have to reference the module in your Bicep file and fill in the relevant parameters. Below you can see a file for a basic blob storage account. 

There are several ways to deploy the code, but one is using Azure CLI, see below:

From VS Code, open a terminal and login to Azure:

> Az Login

If you are using the newest version of Azure CLI, you will be presented with a list of subscriptions available, choose the relevant subscription (alternatively run: az account set <sub name> see more info here).

Navigate to the folder where your Bicep files are located.

Deploy the Bicep with a what-if first (optional):

> az deployment group what-if --resource-group "<resource group name>" --template-file "<bicep file.bicep>"

And to deploy:

> az deployment group create --resource-group "<resource group name>" --template-file "<bicep file.bicep>"

I tried tested out a few of the modules, and they all worked fine. These are:

• Blob storage account
• Private DNS zone (for key vaults)
• Private endpoint with privateDnsZoneGroup (adds A record in PDNS zone), requires existing PDNS zone for blob storage
• Simple Windows virtual machine with public IP
• VNet with one subnet and a VNet peering (requires existing Hub VNet)

The files can be found on GitHub, see link here.

Azure: VNet with VNet peering in bicep

 Here's a bicep file including a module which installs a VNet and a VNet peering to an existing VNet. A VNet peering consists of a local and a remote peering. The remote peering is installed outside the scope of the current deployment (in a different resource group) and so has to be addressed specifically. With ARM templates this is solved by using nested templates. With bicep this is done using modules (a separate bicep file which is referenced from the main bicep file).

The bicep file references an existing VNet (which typically would be a Hub VNet). So this has to be implemented beforehand.

To use the files, simply update the parameters file with relevant info. And update the path to the module in the bicep file. If you deploy using Azure Pipelines or Github Actions make sure that the module file is not placed anywhere where it will be deployed (this throws an error), it should just be referenced.

The files are available here on Github:

vnetWithPeering.bicep

vnetWithPeering.parameters.json

hubPeering_module.bicep

PowerShell and Az CLI commands to deploy ARM templates

 This is just a quick note on the PowerShell command to deploy ARM templates.

Command should be run from the location where the ARM templates are located (or update the file path).

New-AzResourceGroupDeployment -Name deploy_some_storage_account -ResourceGroupName rg-some_resource_group-001 `

  -TemplateFile .\deploy_storage_account.json `

  -TemplateParameterFile .\deploy_storage_account.parameters.json

There is another example here for deploying a key vault.

And here's link to the Microsoft documentation.

For Az CLI the command format is:

az deployment group create --resource-group <resource-group-name> --template-file <path-to-bicep>

More info

Azure Firewall with Azure policy and IP groups using Bicep

 In the previous post I deployed a firewall with some additional components such as VMs, NSGs, and route tables to have a working test setup. In this post it will mainly be the FW, the FW policies and the IP groups that will be deployed.

This post is based on the this Quickstart template with only a few modifications. The main reason I do this is to verify that the files work in my environment to inspect deployed resources.

I have uploaded the modified files to Github (fw-with-policy-001.bicep and fw-with-policy-001.parameters.json). 

The resources deployed can be seen below:

The two IP groups are used in combination with the policy. The policy is associated with the firewall. The are two rule collection groups defined with a total of three rules, see below two screenshots:

Azure: Deploy Azure Firewall in availability zones using Bicep

 Microsoft has some great Quickstart templates for deploying resources as codes. For this post I've looked at deploying an Azure Firewall into multiple availability zones using Bicep.

The Quickstart guide used can be found here.

The template needs only a few changes. I updated the VNet name and IP address info and inserted a reference to a key vault for the VM admin password.

My updated files can be found on Github (fw-conn-weu-001.bicep and fw-conn-weu-001.parameters.json).

The firewall is deployed into three availability zones in West Europe. This increases the availability to 99.99%. There is still only one logical firewall deployed, so the increased availability is managed in the background by Microsoft. And from a Azure Portal point of view it looks the same as if only deploying to one availability zone.

The availability zones can be verified under Azure Firewall -> Properties, see below:

There is no immediate additional cost to deploying to multiple availability zones, however, there is an increased bandwidth cost, see below (or link):

The bicep file deploys the following resources:

If you are testing in a Visual Studio subscription make sure to delete resources again when done as the cost of especially the FW can run up quickly.

One network rule and one application rule are added under Firewall -> Rules (classic) -> Network/Application rule collection tabs, see below. Usually a Firewall Policy will be created and associated with the FW but for testing purposes this can be used.

Using the Bicep visualizer from VS Code you can get a nice graphical overview of the resources to be deployed. To do this, right click the bicep file in VS code and choose "Open Bicep Visualizer", see below: 

Bicep - Add an Azure Key Vault with Access Policies enabled

 As opposed to using ARM templates, you can use Bicep which is also a declarative language but one that is more simple to use than ARM templates.

For this example, I've created a key vault in Bicep, one that I'm using to store local administrator passwords for Windows Servers.

The parameters files are the same as for the ARM template, however, the main template is simpler in Bicep. 

Files are uploaded to Github (kv-mgmt-weu-002.bicep and kv-mgmt-weu-002.parameters.json).

Note that this key vault uses Access Policies as opposed to RBAC for authentication.

I have a regular administrator user which has full access and then there is a service principal (or App Registration) in Azure AD which is configured in Azure DevOps (this is specified in the parameters file). This service principal has permissions to get secrets from the key vault.

In the parameters file the tenant ID (the Azure AD tenant ID) must be specified as well as the object ID of the service principal or any regular users. This can be located in Azure AD, see below:

Bicep file is shown below:

param name string

param location string

param sku string

param accessPolicies array

param tenant string

param enabledForDeployment bool

param enabledForTemplateDeployment bool

param enabledForDiskEncryption bool

param enableRbacAuthorization bool

param publicNetworkAccess string

param enableSoftDelete bool

param softDeleteRetentionInDays int

param networkAcls object

resource name_resource 'Microsoft.KeyVault/vaults@2021-10-01' = {

  name: name

  location: location

  properties: {

    enabledForDeployment: enabledForDeployment

    enabledForTemplateDeployment: enabledForTemplateDeployment

    enabledForDiskEncryption: enabledForDiskEncryption

    enableRbacAuthorization: enableRbacAuthorization

    accessPolicies: accessPolicies

    tenantId: tenant

    sku: {

      name: sku

      family: 'A'

    }

    publicNetworkAccess: publicNetworkAccess

    enableSoftDelete: enableSoftDelete

    softDeleteRetentionInDays: softDeleteRetentionInDays

    networkAcls: networkAcls

  }

  tags: {

  }

  dependsOn: []

}