Deploying a Log Analytics Workspace using Azure Verified Modules (AVM) with Bicep is a streamlined process that leverages the standardized practices of the Azure infrastructure-as-code framework. Here’s a concise guide on how to set up your workspace using the AVM project on GitHub:

The following is example Bicep code, I will let you create the resource group yourself and figure out the tags.

// Log Analytics Parameters
param logAnalyticsSkuName string = ‘PerGB2018’
var logAnalyticsName = ‘law-demo’

@description(‘Log Analytics Daily Quota in GB. Default: 1GB’)
param logAnalyticsDailyQuotaGb int = 1

@description(‘Number of days data will be retained for.’)
param logAnalyticsDataRetention int = 365

//MARK: azureLogAnalytics
@description(‘Deploy Azure Log Analytics’)
module logAnalytics ‘br/public:avm/res/operational-insights/workspace:0.7.0’ = {
scope: resourceGroup(rgLogAnalyticsDemo)
name: ‘logAnalyticsDemo’
params: {
name: logAnalyticsName
skuName: logAnalyticsSkuName
location: location
dailyQuotaGb: logAnalyticsDailyQuotaGb
dataRetention: logAnalyticsDataRetention
tags: tags
}
}

The use of Azure Verified Modules ensures that your infrastructure as code practices align with Microsoft’s standards, simplifying maintenance and scalability concerns. This approach not only streamlines the deployment process but also enhances the security and reliability of your Azure resources.

For more detailed instructions and to view the exact Bicep configurations, visit the GitHub repository pages for Azure Verified Modules and Bicep Registry Modules. These resources will provide you with up-to-date code examples and further details on customizing your deployment.

When managing Azure resources, ensuring your SQL server is secure from unauthorized access is a priority. One way to secure your Azure SQL server is by implementing firewall rules. In this post, I’ll guide you through using Bicep and the Azure Verified Modules from GitHub to set up firewall rules for an Azure SQL server.

Example Bicep:

@description('Deploy Azure SQL Server')
 module createsqlServer '../sql/server/main.bicep' = {
   scope: resourceGroup(rgSQL)
   name: 'sqlServer-${environmentName}'
   params: {
     name: 'sql-demoserver'
     administratorLogin: administratorLogin
     administratorLoginPassword: administratorLoginPassword
     managedIdentities: {
       systemAssigned: false
       userAssignedResourceIds: [
         createManagedIdentity.outputs.resourceId
       ]
     }
     primaryUserAssignedIdentityId: createManagedIdentity.outputs.resourceId
     location: location
     tags: tags
     databases: [
        {
          name: 'demidb1'
          skuName: 'ElasticPool'
          skuTier: 'GeneralPurpose'
          capacity: 0
          maxLogSizeBytes: 34359738368
          compatibilityLevel: 120
          elasticPoolId: createSqlServerElasticPool.outputs.resourceId
        }
     ]
     firewallRules: [
      {
        name: '<database firewall rule 1>'
        startIpAddress: 'enter ip address here'
        endIpAddress: 'enter ip address here'
      }
      {
       name: '<database firewall rule 2>'
       startIpAddress: '<enter ip address here>'
       endIpAddress: '<enter ip address here>'
      }
   ]
   }
 }

This Bicep file defines 2 simple rule that allows traffic from certain defined IP addresses. Be sure to adjust the startIpAddress and endIpAddress to fit your security requirements. This example doesn’t show the code for the creation of the elasticPool or the Managed Identity.

This example serves as a foundational guide to get you started with automated deployment of firewall rules using Infrastructure as Code (IaC) practices with Bicep.

Introduction

Azure Firewall is a powerful cloud-native service that provides network security across your Azure environment. Managing traffic in and out of your virtual networks requires a precise and structured approach, and Azure Firewall helps achieve this with rule collection groups and rules. In this guide, we will explore how to use the Azure Verified Modules GitHub project. For more details, see the official Microsoft documentation on Azure Firewall rule collections. to enable Windows Updates and Time Server synchronization by configuring Azure Firewall rule collection groups.

What Are Azure Firewall Rule Collection Groups?

Azure Firewall’s rules are organized into rule collection groups and rules. This structure helps you maintain and manage the settings effectively.

• Rule Collection Groups: These are containers for organizing rule collections by priority. You can think of them as a way to categorize rules that have similar purposes.
• Rule Collections: Inside a group, rule collections are the actual sets of rules that Azure Firewall enforces. Rule collections are defined based on the type of traffic they manage—network rules, application rules, or NAT rules.
• Rules: Finally, within each rule collection, you define the specific rules that manage traffic. These rules control things like which IP addresses can communicate through which ports and protocols.

When working with Azure Firewall, setting up rules for basic functionalities like Windows Updates or Time Server synchronization may seem straightforward, but it can require detailed settings that can benefit from automation and consistency. This is where Microsoft’s Azure Verified Modules come in.

Azure Verified Modules GitHub Project

Microsoft provides the Azure Verified Modules. You can also refer to the Azure Firewall documentation for a broader understanding of firewall management. GitHub project to simplify and standardize Azure infrastructure deployments. These modules are built to help you achieve common tasks in Azure using well-defined Infrastructure as Code (IaC) practices. They leverage tools like Bicep and ARM templates, providing verified configurations that are reliable, repeatable, and secure.

We will use this project to configure Azure Firewall to allow Windows Updates and NTP (Network Time Protocol) server synchronization.

Setting Up Azure Firewall Rules for Windows Updates and Time Sync

To enable Windows Updates and time server synchronization, you need to create specific rule collection groups and rules. These rules will allow Azure virtual machines to reach Microsoft’s update servers and time servers.

Note you can either clone the repo or make use of the public repo that Azure provide, below shows you how to clone the repo.

Step 1: Cloning the Verified Modules Repository

Start by cloning the Azure Verified Modules repository:

# Clone the repository
git clone https://github.com/Azure/Azure-Verified-Modules

Step 2: Understanding the Module Structure

In the repository, you will find modules for managing Azure Firewall rule collections. The folder structure helps you locate different types of rule collections (such as Network Rules, Application Rules, and NAT Rules).

For enabling Windows Updates and time synchronization, we will focus on Application Rule Collections. Application rules are ideal for this scenario as they define fully qualified domain names (FQDNs) to allow outbound HTTP/S traffic, which is the type of traffic used for both updates and NTP.

Step 3: Using the Application Rules Module

Navigate to the module related to Firewall Application Rules. The module you need allows Azure Firewall to be configured with outbound rules for reaching well-known domains, like Windows Update servers and NTP servers. For more details, you can refer to the official documentation on Azure Firewall application rules.

The basic configuration requires defining a rule collection group that contains an application rule collection for the update and time synchronization domains.

Example Bicep File

Below is an example Bicep configuration that uses Azure Firewall to create rules allowing Windows Updates and NTP. Refer to the Azure Bicep documentation for more information on using Bicep to manage Azure resources.

param firewallName string
param resourceGroupName string
param location string = resourceGroup().location
param windowsUpdateDomains array = [
  'windowsupdate.microsoft.com',
  '*.windowsupdate.microsoft.com',
  '*.update.microsoft.com',
  '*.delivery.mp.microsoft.com'
]
param ntpDomains array = [
  'time.windows.com'
]

resource firewall 'Microsoft.Network/azureFirewalls@2021-08-01' existing = {
  name: firewallName
  resourceGroup: resourceGroupName
}

resource appRuleCollection 'Microsoft.Network/azureFirewalls/ruleCollections@2021-08-01' = {
  name: '${firewallName}-app-rule-collection'
  parent: firewall
  properties: {
    priority: 200
    ruleCollectionType: 'FirewallPolicy'
    rules: [
      {
        name: 'Allow-Windows-Updates'
        ruleType: 'ApplicationRule'
        targetFqdns: windowsUpdateDomains
        protocols: [
          {
            protocolType: 'Https'
            port: 443
          }
        ]
      }
      {
        name: 'Allow-NTP-Sync'
        ruleType: 'ApplicationRule'
        targetFqdns: ntpDomains
        protocols: [
          {
            protocolType: 'Https'
            port: 443
          }
        ]
      }
    ]
  }
}

Explanation of the Bicep Configuration

• Parameters: The script defines several parameters, including the firewall name, resource group, and domains for Windows Updates and NTP.
• Firewall Resource: The firewall resource is defined as an existing resource, meaning that the script expects the Azure Firewall to already be deployed.
• Application Rule Collection: This rule collection contains two application rules—one for Windows Updates and one for NTP. Each rule targets the necessary FQDNs and specifies HTTPS (port 443) as the protocol.

Step 4: Deploying the Bicep File

To deploy this Bicep file, use the following Azure CLI command:

az deployment group create \
  --resource-group <YourResourceGroupName> \
  --template-file <PathToYourBicepFile>.bicep

Replace <YourResourceGroupName> and <PathToYourBicepFile> with your specific values. This command will deploy the rule collection group to your existing Azure Firewall.

Verifying the Configuration

Once the deployment is complete, it is important to verify that the Azure Firewall is properly configured to allow the necessary traffic. You can also refer to the Azure Firewall verification steps in the official Microsoft Docs for additional troubleshooting and validation methods.

• Windows Updates: You can verify if Windows Updates are working by manually triggering an update check on a virtual machine. If configured correctly, the VM should reach Microsoft’s update servers without issues.
• NTP Synchronization: For NTP, you can verify the time sync status by running the following command on a Windows VM:w32tm /query /statusThis command should display the synchronization details if the connection to the NTP server is successful.

Best Practices for Managing Firewall Rules

When managing Azure Firewall rules, it is crucial to follow a few best practices to keep your infrastructure secure and manageable. Microsoft provides a set of best practices that you can find in their official documentation:

• Organize Rules by Function: Group rules by their function—for example, rules for Windows Updates, security services, etc. This makes it easier to manage and understand.
• Use Appropriate Priorities: Rule priorities determine the order in which they are evaluated. Ensure that more specific rules have higher priorities (lower numerical values).
• Minimize Wildcards: Avoid using wildcards (*) in domain names as much as possible. While convenient, they can open unnecessary access and compromise security.
• Test Thoroughly: Always test new rules in a controlled environment before applying them in production. This helps to avoid disruptions.

Real world example

param firewallPolicyName string
param appGatewaySubnetAddress string 
param vmSubnetAddress string
param location string

resource updateAzureFirewallPolicy 'Microsoft.Network/firewallPolicies@2024-01-01' = {
  name: firewallPolicyName
  location:location
  properties: {
    sku: {
      tier: 'Premium'
    }
    threatIntelMode: 'Deny'
    threatIntelWhitelist: {
      fqdns: []
      ipAddresses: []
    }
    dnsSettings: {
      servers: []
      enableProxy: true
    }
    sql: {
      allowSqlRedirect: false
    }
    intrusionDetection: {
      mode: 'Deny'
      configuration: {
        signatureOverrides: []
        bypassTrafficSettings: []
        privateRanges: [
          '172.16.0.0/12'
         ]
      }
    }
  }
}

resource createAzureFireWallServerActivationRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2024-01-01' = {
  parent: updateAzureFirewallPolicy
  name: 'ServerActivation'
  properties: {
    priority: 2900
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'KMS'
            ipProtocols: [
              'TCP'
            ]
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            sourceIpGroups: []
            destinationAddresses: []
            destinationIpGroups: []
            destinationFqdns: [
              'kms.core.windows.net'
            ]
            destinationPorts: [
              '1688'
            ]
          }
          {
            ruleType: 'NetworkRule'
            name: 'AppGatewaytoCustomer'
            ipProtocols: [
              'TCP'
            ]
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            sourceIpGroups: []
            destinationAddresses: [
              vmSubnetAddress
            ]
            destinationIpGroups: []
            destinationFqdns: []
            destinationPorts: [
              '8080'
              '443'
            ]
          }
          {
            ruleType: 'NetworkRule'
            name: 'AllowWindowsTimeServer'
            ipProtocols: [
              'UDP'
            ]
            sourceAddresses: [
              '*'
            ]
            sourceIpGroups: []
            destinationAddresses: []
            destinationIpGroups: []
            destinationFqdns: [
              'time.windows.com'
            ]
            destinationPorts: [
              '123'
            ]
          }
          {
            ruleType: 'NetworkRule'
            name: 'AllowAzureBackupAllowMonitor'
            ipProtocols: [
              'TCP'
            ]
            sourceAddresses: [
              '*'
            ]
            sourceIpGroups: []
            destinationAddresses: [
              'AzureBackup'
              'AzureMonitor'
            ]
            destinationIpGroups: []
            destinationFqdns: []
            destinationPorts: [
              '*'
            ]
          }
          {
            ruleType: 'NetworkRule'
            name: 'msedge.api.cdp.microsoft.com'
            ipProtocols: [
              'TCP'
            ]
            sourceAddresses: [
              '*'
            ]
            sourceIpGroups: []
            destinationAddresses: []
            destinationIpGroups: []
            destinationFqdns: [
              'msedge.api.cdp.microsoft.com'
            ]
            destinationPorts: [
              '*'
            ]
          }
          {
            ruleType: 'NetworkRule'
            name: 'AllowLinuxTimeServer'
            ipProtocols: [
              'UDP'
            ]
            sourceAddresses: [
              '*'
            ]
            sourceIpGroups: []
            destinationAddresses: []
            destinationIpGroups: []
            destinationFqdns: [
              'ntp.ubuntu.com'
            ]
            destinationPorts: [
              '*'
            ]
          }
        ]
        name: 'ServerActivation'
        priority: 2900
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'Ubuntu Updates'
            protocols: [
              {
                protocolType: 'Http'
                port: 80
              }
              {
                protocolType: 'Https'
                port: 443
              }
            ]
            fqdnTags: []
            webCategories: []
            targetFqdns: [
              '*.ubuntu.com'
            ]
            targetUrls: []
            terminateTLS: false
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            destinationAddresses: []
            sourceIpGroups: []
            httpHeadersToInsert: []
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Windows Updates'
            protocols: [
              {
                protocolType: 'Http'
                port: 80
              }
              {
                protocolType: 'Https'
                port: 443
              }
            ]
            fqdnTags: [
              'WindowsUpdate'
              'WindowsDiagnostics'
            ]
            webCategories: []
            targetFqdns: []
            targetUrls: []
            terminateTLS: false
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            destinationAddresses: []
            sourceIpGroups: []
            httpHeadersToInsert: []
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Azure Monitor'
            protocols: [
              {
                protocolType: 'Http'
                port: 8080
              }
              {
                protocolType: 'Https'
                port: 443
              }
            ]
            fqdnTags: []
            webCategories: []
            targetFqdns: [
              '*.azure.com'
              '*.windows.net'
            ]
            targetUrls: []
            terminateTLS: false
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            destinationAddresses: []
            sourceIpGroups: []
            httpHeadersToInsert: []
          }
        ]
        name: 'LinuxUpdates'
        priority: 3000
      }
    ]
  }
}

resource createAzureFireWallTimeSyncRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2024-01-01' = {
  parent: updateAzureFirewallPolicy
  name: 'TimeSync'
  properties: {
    priority: 2000
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'TimeSync'
            ipProtocols: [
              'Any'
            ]
            sourceAddresses: [
              appGatewaySubnetAddress
            ]
            sourceIpGroups: []
            destinationAddresses: [
              '*'
            ]
            destinationIpGroups: []
            destinationFqdns: []
            destinationPorts: [
              '123'
            ]
          }
        ]
        name: 'TimeSync'
        priority: 2000
      }
    ]
  }
  dependsOn:[
    createAzureFireWallServerActivationRuleCollectionGroup
  ]
}

Conclusion

Configuring Azure Firewall with rule collection groups and rules for enabling Windows Updates and time server synchronization is an important part of managing Windows workloads in Azure. By leveraging Microsoft’s Azure Verified Modules from GitHub, you can automate the deployment of these configurations, ensuring a consistent and reliable approach.

Using the example Bicep script above, you can quickly implement rules that allow your VMs to stay updated and correctly synchronized with Microsoft’s time servers, all while maintaining a secure and organized firewall configuration. Azure Firewall, combined with the automation provided by these verified modules, makes network management simpler and more effective.

When setting up your infrastructure in Azure, using the Azure Verified Modules can streamline the creation of any Azure Resource such as Azure Web Apps for Windows and Linux with App Service Plans. This post guides you through the code for doing just that, I leave it to you to create the parameters and fill them in 🙂

//MARK: App Insights Instance
@description('Create Application Insights Instance')
module createAppInsights 'br/public:avm/res/insights/component:0.4.1' = if (deployWebApps) {
  scope: resourceGroup(resourceGroupArray[2].name)
  name: 'createAppInsights'
  params: {
    name: appInsightsName
    workspaceResourceId: logAnalytics.outputs.resourceId
    diagnosticSettings: [
      {
        workspaceResourceId: logAnalytics.outputs.resourceId
      }
    ]
  }
  dependsOn: [
    logAnalytics
  ]
}

//MARK: App Service Plan Windows
//Deploy an azure web app with App service plan for Windows
module appServicePlanWindows 'br/public:avm/res/web/serverfarm:0.2.4' = if (deployWebApps) {
  scope: resourceGroup(resourceGroupArray[2].name)
  name: 'appServicePlanWindows'
  params: {
    name: 'aspwin-${customerName}-${environmentName}-${locationShortCode}'
    location: location
    tags: tags
    skuName: skuNameAppServicePlanWindows
    kind: skuKindAppServicePlanWindows
    skuCapacity: skuCapacityAppServicePlanWindows
    diagnosticSettings: [
      {
        workspaceResourceId: logAnalytics.outputs.resourceId
      }
    ]
  }
  dependsOn: [
    logAnalytics
  ]
}

//MARK: App Service Windows
module appServiceWindows 'br/public:avm/res/web/site:0.9.0' = if (deployWebApps) {
  scope: resourceGroup(resourceGroupArray[2].name)
  name: 'appService'
  params: {
    name: 'appwin-${customerName}-${environmentName}-${locationShortCode}'
    kind: 'app'
    location: location
    tags: tags
    serverFarmResourceId: appServicePlanWindows.outputs.resourceId
    managedIdentities: {
      systemAssigned: false
      userAssignedResourceIds: [
        managedIdentity.id
      ]
    }
    diagnosticSettings: [
      {
        workspaceResourceId: logAnalytics.outputs.resourceId
      }
    ]
    siteConfig: {
      alwaysOn: true
      http20Enabled: false
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: createAppInsights.outputs.instrumentationKey
        }
      ]
    }
    appInsightResourceId: createAppInsights.outputs.resourceId
  }
  dependsOn: [
    logAnalytics
    appServicePlanWindows
    createAppInsights
  ]
}

//MARK: App Service Plan Linux
//Deploy an azure web app with App service plan for Linux
module appServicePlanLinux 'br/public:avm/res/web/serverfarm:0.2.4' = if (deployWebApps) {
  scope: resourceGroup(resourceGroupArray[2].name)
  name: 'appServicePlanLinux'
  params: {
    name: 'asplinux-${customerName}-${environmentName}-${locationShortCode}'
    location: location
    tags: tags
    skuName: 'P1v3'
    kind: skuKindAppServicePlanLinux
    zoneRedundant: false
    diagnosticSettings: [
      {
        workspaceResourceId: logAnalytics.outputs.resourceId
      }
    ]
  }
  dependsOn: [
    logAnalytics
  ]
}

//MARK: App Service Linux
module appServiceLinux 'br/public:avm/res/web/site:0.9.0' = if (deployWebApps) {
  scope: resourceGroup(workloadsResourceGroupArray[2].name)
  name: 'appServiceLinux'
  params: {
    name: 'applin-${customerName}-${environmentName}-${locationShortCode}'
    kind: 'app'
    location: location
    tags: tags
    serverFarmResourceId: appServicePlanLinux.outputs.resourceId
    managedIdentities: {
      systemAssigned: false
      userAssignedResourceIds: [
        managedIdentity.id
      ]
    }
    diagnosticSettings: [
      {
        workspaceResourceId: logAnalytics.outputs.resourceId
      }
    ]
    siteConfig: {
      alwaysOn: true
      http20Enabled: false
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: createAppInsights.outputs.instrumentationKey
        }
      ]
    }
    appInsightResourceId: createAppInsights.outputs.resourceId
  }
  dependsOn: [
    logAnalytics
    appServicePlanLinux
    createAppInsights
  ]
}

This code will now create an a Windows App Service Plan with a Web App, a Linux App Service Plan with a Web App and also an Application Insights instance and hook up both web apps to the same App Insights instance for monitoring.
Yes this code could be tidied up even further but the purpose it so show you how easy it can be to deploy resources using Bicep along with the Azure Verified Modules github repository.

When setting up your infrastructure in Azure, using the Azure Verified Modules can streamline the creation of any Azure Resource such as an Azure SQL Server, an Elastic Pool, and 2 demo databases. This post guides you through the code for doing just that, I leave it to you to create the parameters and fill them in 🙂

Bicep Code

//MARK: SQL Server
@description('SQL Server')
module sqlServer 'br/public:avm/res/sql/server:0.8.0' = if (deploySQLServer) {
  scope: resourceGroup("resourceGroupArray[4].name")
  name: 'sqlServer-${environmentName}'
  params: {
    name: sqlServerName
    administratorLogin: sqlAdministratorLogin
    administratorLoginPassword: keyVault.getSecret(config.kvSQLPassword)
    managedIdentities: {
      systemAssigned: false
      userAssignedResourceIds: [
        managedIdentity.id
      ]
    }
    primaryUserAssignedIdentityId: managedIdentity.id
    location: location
    tags: tags
    databases: [
      {
        name: 'demodb1'
        maxSizeBytes: 2147483648
        skuName: 'ElasticPool'
        skuTier: 'GeneralPurpose'
        zoneRedundant: false
        capacity: 0
        elasticPoolId: 'subscriptions/${subscriptionId}/resourceGroups/${resourceGroupArray[4].name}/providers/Microsoft.Sql/servers/${sqlServerName}/elasticpools/${elasticPoolName}'
      }
      {
        name: 'demodb2'
        maxSizeBytes: 2147483648
        skuName: 'ElasticPool'
        skuTier: 'GeneralPurpose'
        zoneRedundant: false
        capacity: 0
        elasticPoolId: 'subscriptions/${subscriptionId}/resourceGroups/${resourceGroupArray[4].name}/providers/Microsoft.Sql/servers/${sqlServerName}/elasticpools/${elasticPoolName}'
      }
    ]
    elasticPools: [
      {
        maxSizeBytes: 34359738368
        name: elasticPoolName
        perDatabaseSettings: {
            minCapacity: 0
            maxCapacity: 2
        }
        skuCapacity: 2
        skuName: 'GP_Gen5'
        skuTier: 'GeneralPurpose'
        zoneRedundant: false
        maintenanceConfigurationId: '/subscriptions/${subscriptionId}/providers/Microsoft.Maintenance/publicMaintenanceConfigurations/SQL_Default'
      }
    ]
  }
}

This code will now create an Azure SQL Server, an Elastic Pool and 2 demo databases within the Elastic Pool. Yes this code could be tidied up even further but the purpose it so show you how easy it can be to deploy resources using Bicep along with the Azure Verified Modules github repository.