Describe the bug

When using either of the included scripts:

• https://github.com/Azure/ALZ-Bicep/blob/main/docs/scripts/createRGandcallBicep.ps1
• https://github.com/Azure/ALZ-Bicep/blob/main/docs/scripts/createRGandcallBicep.sh

The modules that sit in https://github.com/Azure/ALZ-Bicep/tree/main/infra-as-code/bicep/modules/policy are not published e.g:

• modules\policy\assignments\policyAssignmentManagementGroup.bicep
• modules\policy\definitions\custom-policy-definitions.bicep

This is due to the path being used of infra-as-code/bicep/modules//.bicep

To Reproduce

Steps to reproduce the behaviour:

1. Execute either script
2. Validate that the policy modules have not been published

Expected behaviour

I would have expected those modules to be published so that they can be referenced as remote modules.

Screenshots 📷

Published Modules:

Correlation ID

N/A

Additional context

I will raise another issue (question) to validate some of how I am ingesting/implementing the outputs of this repository as it is not especially clear from some of the documentation on what the best practice would be.

Describe the solution you'd like

Add note to FAQ on how to get alerted for new releases for ALZ-Bicep

Couple of options:

1. Use the "watch" feature
   
2. Use https://newreleases.io/

Describe alternatives you've considered

N/A

Additional context

N/A

Question/Feedback

Adding a Service Principal to deploy ALZ-Bicep. PR will be created to add Deploying ALZ-Bicep Pre Requisites

Possible Answers/Solutions?

Grant Access to the Service Principal

PowerShell:

#API calls have migrated from AAD Graph to Microsoft Graph 
Install-Module Microsoft.Graph -AllowClobber -Force
Connect-Graph -Scopes "User.Read","Application.Read.All"
$spn = (Get-MgServicePrincipal -Filter "DisplayName eq '$ServicePrincipalName'")
New-AzRoleAssignment -Scope '/' -RoleDefinitionName 'Owner' -ObjectId $spn.Id

#Connect/Use Service Principal
$SecuredPassword = ConvertTo-SecureString -String $secretValue -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential ($ApplicationId, $SecuredPassword)
Connect-AzAccount -ServicePrincipal -TenantId $TenantId -Credential $Credential

Describe the solution you'd like

The current creation of subscriptions places the subscription in the Tenant Root Group or other default management group.

I would like to add the "move feature" to this Bicep template. This will be an optional feature and uses the parManagementGroupId to define the subscription placement location. I am not sure if this feature fits the vision of the repository, so that's why I made this request.

Describe the solution you'd like

I recommend moving the Private DNS Zones for Private Link scenarios to a separate Resource Group.

In actual customer environments, it has been found that DNS management is often managed administratively differently than firewall or hub network management.

Furthermore, Azure RBAC rules that affect DNS records are much easier to control if the collected DNS zones are kept in their own resource group. Also any Azure Policies (as described in Issue #137) can be assigned more explicitly (from my point of view).

In addition, this change results in a much clearer resource group for the hub network.

Describe alternatives you've considered

To solve it, we did two things:

1. We rolled out the "hubNetworking" module with private DNS zones disabled (to avoid breaking the "API" so to speak - we didn't change the original hubNetworking.bicep module).

   Example from our Deployment Bicep file:

   module hubNetworking '../infra-as-code/bicep/modules/hubNetworking/hubNetworking.bicep' = {
     scope: hubNetworkingRg
     name: 'hubNetworking'
     params: {
       parRegion: location
       parAzureFirewallEnabled: true
       parAzureFirewallTier: 'Standard'
       parCompanyPrefix: 'swo'
       parPrivateDNSZonesEnabled: false
       parExpressRouteGatewayConfig: {}
     }
   }
   

2. We implemented another module "privateDnsZones", which is essentially a copy of "hubNetworking" in terms of the private DNS zones (comes after this report as a pull request), and rolled it out as follows:

   module privateDnsZones '../infra-as-code/bicep/modules/privateDnsZones/privateDnsZones.bicep' = {
     scope: privateDnsZoneRg
     name: 'privateDnsZones'
     params: {
       parRegion: location
       parPrivateDNSZonesEnabled: true
       parHubVirtualNetworkId: hubNetworking.outputs.outHubVirtualNetworkID
     }
   }

Additional context

Our whole deployment Bicep file (placed at ./deployment/hubNetworking.bicep) for this environment looks like this:

// Deploy Hub Network in SWON environment

targetScope = 'subscription'

param location string = 'westeurope'

resource hubNetworkingRg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-core-network-weu-01'
  location: location
}

resource privateDnsZoneRg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-privatednszones-weu-01'
  location: location
}

module hubNetworking '../infra-as-code/bicep/modules/hubNetworking/hubNetworking.bicep' = {
  scope: hubNetworkingRg
  name: 'hubNetworking'
  params: {
    parRegion: location
    parAzureFirewallEnabled: true
    parAzureFirewallTier: 'Standard'
    parCompanyPrefix: 'swo'
    parDDoSEnabled: false
    parPrivateDNSZonesEnabled: false
    parExpressRouteGatewayConfig: {}
  }
}

module privateDnsZones '../infra-as-code/bicep/modules/privateDnsZones/privateDnsZones.bicep' = {
  scope: privateDnsZoneRg
  name: 'privateDnsZones'
  params: {
    parRegion: location
    parPrivateDNSZonesEnabled: true
    parHubVirtualNetworkId: hubNetworking.outputs.outHubVirtualNetworkID
  }
}

Describe the solution you'd like

Currently several public IP addresses are created for numerous services in the hub networking module, this includes:

• Azure Firewall
• VPN/ Expression Gateway
• Azure Bastion

Currently there is a configuration for availability zones supported with Azure Firewall which also sets the zones property of the public IP address through the parAzureFirewallAvailabilityZones parameter.

For VPN/ ER gateways, to fully support availability zones a AZ SKU + a public IP across more then one zone is required for zone redundancy. If you deploy via that Azure Portal, the Zone Redundancy option includes zones 1, 2, 3.

Currently I can't see any docs specifically calling out if Azure Bastion supports availability zones and the resource configuration does not have a telling zones property so I will assume not.

The other PIPs ideally should support availability zones to align to Well-Architected Framework (WAF) recommendation for reliability when a region supports it.

Additional context

This is reported by PSRule for Azure: https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.PublicIP.AvailabilityZone/

Related to #206

Describe the solution you'd like

Add new Private DNS Zones that were added to Portal experience to make the ALZ-Bicep same in future parity

Describe the solution you'd like

AZs are now supported for Azure Firewalls deployed in the Secure vHub model (Virtual WAN) as per https://azure.microsoft.com/en-us/blog/boost-your-network-security-with-new-updates-to-azure-firewall & https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-faq#how-are-availability-zones-and-resiliency-handled-in-virtual-wan

This change looks to be to add the zones property to the Azure Firewall in vwanConnectivity.bicep and expose as a parameter and default to a sensible value (TBC)

Describe alternatives you've considered

N/A

Additional context

This is also being done in the ALZ Accelerator Azure/Enterprise-Scale#955

See upstream issue Azure/Enterprise-Scale#979

Describe the solution you'd like

Add 2 Required Log Analytics Solutions for SQL Assessments for MDFC.

Missing Solutions:

• SQLVulnerabilityAssessment
• SQLAdvancedThreatProtection

"product": "OMSGallery/SQLAdvancedThreatProtection",
"publisher": "Microsoft"

&

"product": "OMSGallery/SQLVulnerabilityAssessment",
"publisher": "Microsoft"

Describe alternatives you've considered

N/A

Additional context

Raised from customer engagement wash-up call and also mentioned here https://youtu.be/o9wHIS_QLJE?t=1279

Today all of the modules that deploy resources into resource groups expect the resource groups exist or are created outside of the module.

We are investigating the inclusion of resource group creation within the modules themselves; however, there are technical constraints in how the solution will work and we'd like to hear from the community to understand if including resource group creation within the modules is worth the effort.

** WE WANT YOU TO HELP US DECIDE THE FUTURE BY VOTING (SEE BELOW) *

Please read the remainder of this issue for context and then have your voice heard by voting at the following link:
VOTE HERE

We'd ❤️ to hear from you, so if you have any other thoughts/ideas/questions, please leave a comment.

Technical Constraints

• Bicep templates deploying resource groups target the subscription scope
• Bicep templates deploying resources into resource groups target the resourceGroup scope
• Since deploying the required resource groups and then resources target different deployment scopes, it is not possible to combine everything into a single Bicep template.

Proposed "Module Inclusion" Solution

The proposed solution to deal with the above technical constraints are as follows:

• Each module requiring a resource group creation would have a "wrapper" Bicep template added.
• The "wrapper" Bicep template would be the entry point for modules requiring resource groups and you would change your deployment to target the subscription scope instead of resourceGroup scope
• The "wrapper template will invoke two module deployments:
  1. Resource group at subscription scope
  2. Resource deployment targeting the just deployed resource Group as the deployment scope
• With this "wrapper" approach, the existing Bicep files deploying module resources will remain intact which means you could still deploy the modules resources only. However, file locations may move to keep things organized.

A preview of what this change for looks like for the hubNetworking module can be viewed here:
https://github.com/rjygraham/ALZ-Bicep/pull/1/files

In this example, the "wrapper" template is infra-as-code/bicep/modules/hubNetworking/resourceGroup/hubNetworkingResourceGroup.bicep and the resource template is moved from the module root to the resources folder.

Pros of "Module Inclusion" approach

• Aligns closely with the vision of ALZ-Bicep having modules that are independent deployable units
• (Hypothesis) This approach is more user friendly to those less familiar with Azure
• Provides flexibility for ALZ-Bicep consumer to choose whether to deploy a module resources with or without the resource group as part of the template
• Simplified CI/CD pipelines:
  • Removes any steps to pre-create the required resource group
  • If you were using AZ CLI or Azure PowerShell steps to deploy ALZ-Bicep based on the deployment snippets in the module README, you could simplify and use the native Azure ARM tasks/steps within Azure DevOps/GitHub Actions.

Cons of "Module Inclusion" approach

• Bicep templates don't have the notion of inheritance and therefore any parameters or outputs in the Bicep template deploying resources will need to be duplicated in the "wrapper" template
  • This adds maintenance overhead as ALZ-Bicep and individual modules evolve
  • May add friction to contributions from community members as it would not be immediately apparent that parameters and outputs from the resource Bicep template need to be copied to the "wrapper" template
• Documenting the two deployment modalities is challenging:
  • Consolidating documentation for deploying the module resources or module resource group and resources in a single README is a bit messy
  • Splitting documentation into two separate documents would require duplicating large markdown tables detailing the parameters and outputs - these would need to be kept sync
• Have to consider how we maintain organization and consistency across modules targeting the subscription scope vs modules targeting the resourceGroup scope

An "Orchestrator" alternative

An alternative to including module resource group creation in the modules themselves would be to include resource group creation in an "orchestrator" type template. The "orchestrator" template would deploy some (or all) modules sequenced in the correct order and ensure required resource groups are created before deploying modules.

Pros of the "orchestrator" approach

• Most pros of the "Module Inclusion" approach
• Module documentation remains straight forward
• No longer issues with maintaining organization and consistency across modules targeting the subscription scope vs modules targeting the resourceGroup scope

Cons of the "orchestrator" approach

• Still have the issue of copying parameters and outputs from the module Bicep template to the "orchestrator" template; however, this will need to be done if we decide to implement an "orchestrator" template anyway.
• Deviates from the vision of ALZ-Bicep having modules that are independent deployable units

The CUA mechanism is being used to allow tracking of the various modules and for Microsoft to provide better support.

However, Customer Usage Attribution is one of the mechanisms used to recognise partner attached ACR. It isn't the preferred mechanism - CSP and PAL are more robust - but is still valid and the repo should enable its use.

I suggest that the repo introduces a consistently named parameter, e.g. CUA_GUID, to all modules so that a partner specified GUID can filter through the modules. The parameter value would be set to the GUID generated and registered by the partner.

Describe the solution you'd like

Support for private DNS records auto creation in central connectivity subscription and of creation of private DNS zones in Corp landing zone. Docs: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale

Describe alternatives you've considered

Policy Definitions are in place. Could be good to have a feature toggle (true & false). Support for multi-region would be great but for first iteration one region would suffice.

Additional context

Add any other context or screenshots about the feature request here. 📷

Question/Feedback

I have some general questions of best practice around ingesting and extending the output of this module.

Fundamentally:

• What are the options for consuming the outputs of this repository?
• What are the pros/cons for each?
• Are there product roadmap considerations? e.g. Bicep public module registry

Although generally implementation and decisions are down to the consumer of the module repos I haven't found it clear what the options are available which makes this harder to use.

Possible Answers/Solutions?

• I could fork this repository (not marked as template though), then add my pipelines and extend the functionality.
• I have seen that there is documentation for private modules - so I could create an ACR publish these modules and consume in my own repository

Perhaps there are other options available as well that I am not considering?

Certainly there is a mix of approach in this repository with the majority of the examples and pipelines referencing the local modules and infact I have done both of the options that I suggested above with differing success.

Describe the bug

A list of policy definitions are shown as invalid in the error message.

To Reproduce

Steps to reproduce the behaviour:

1. Run the pipeline with the following env: variables values:

env:
  ManagementGroupPrefix: "alz07"
  TopLevelManagementGroupDisplayName: "Azure Landing Zones"
  Location: "centralus"
  LoggingSubId: "redacted"
  LoggingResourceGroupName: "alz-logging-rgp-01"
  HubNetworkSubId: "redacted"
  HubNetworkResourceGroupName: "alz-network-hub-rgp-01"
  RoleAssignmentManagementGroupId: "alz07"
  SpokeNetworkSubId: "redacted"
  SpokeNetworkResourceGroupName: "spoke-networking-rgp-01"
  runNumber: ${{ github.run_number }}

Expected behaviour

Pipeline runs without error and deploys the platform and landing zones.

Screenshots 📷

Correlation ID

A correlation ID really helps us investigate your issue further. Please provide one if possible. Details on how to find a correlation ID can be found here: Correlation ID and support

3c8058dc-ca85-4731-92f3-fbc76f96d8f3

Additional context

{
    "status": "Failed",
    "error": {
        "code": "InvalidCreatePolicySetDefinitionRequest",
        "message": "The policy set definition 'Deploy-Diagnostics-LogAnalytics' request is invalid. Policy definitions should be specified only at or above the policy set definition's scope. The following policy definitions are invalid: 'Deploy-Diagnostics-ACI,Deploy-Diagnostics-ACR,Deploy-Diagnostics-AnalysisService,Deploy-Diagnostics-ApiForFHIR,Deploy-Diagnostics-APIMgmt,Deploy-Diagnostics-ApplicationGateway,Deploy-Diagnostics-WebServerFarm,Deploy-Diagnostics-Website,Deploy-Diagnostics-AA,Deploy-Diagnostics-CDNEndpoints,Deploy-Diagnostics-CognitiveServices,Deploy-Diagnostics-CosmosDB,Deploy-Diagnostics-Databricks,Deploy-Diagnostics-DataExplorerCluster,Deploy-Diagnostics-DataFactory,Deploy-Diagnostics-DLAnalytics,Deploy-Diagnostics-EventGridSub,Deploy-Diagnostics-EventGridTopic,Deploy-Diagnostics-EventGridSystemTopic,Deploy-Diagnostics-ExpressRoute,Deploy-Diagnostics-Firewall,Deploy-Diagnostics-FrontDoor,Deploy-Diagnostics-Function,Deploy-Diagnostics-HDInsight,Deploy-Diagnostics-iotHub,Deploy-Diagnostics-LoadBalancer,Deploy-Diagnostics-LogicAppsISE,Deploy-Diagnostics-MariaDB,Deploy-Diagnostics-MediaService,Deploy-Diagnostics-MlWorkspace,Deploy-Diagnostics-MySQL,Deploy-Diagnostics-NIC,Deploy-Diagnostics-NetworkSecurityGroups,Deploy-Diagnostics-PostgreSQL,Deploy-Diagnostics-PowerBIEmbedded,Deploy-Diagnostics-RedisCache,Deploy-Diagnostics-Relay,Deploy-Diagnostics-SignalR,Deploy-Diagnostics-SQLElasticPools,Deploy-Diagnostics-SQLMI,Deploy-Diagnostics-TimeSeriesInsights,Deploy-Diagnostics-TrafficManager,Deploy-Diagnostics-VM,Deploy-Diagnostics-VirtualNetwork,Deploy-Diagnostics-VMSS,Deploy-Diagnostics-VNetGW,Deploy-Diagnostics-WVDAppGroup,Deploy-Diagnostics-WVDHostPools,Deploy-Diagnostics-WVDWorkspace'."
    }
}

Describe the solution you'd like

I'm trying to get ALZ implementation which is done with combination of 3rd party tool(s) and manual work under control with these modules and prefer doing it on way that I would be able to use these modules without customizations so I can have automation which syncs latest module versions to our GIT repo with pull requests.

However I found some limitation which prevents me to doing it so opening this issue to discuss if those changes makes sense.
Changes which I would like to see on managementGroups module are:

• Landing Zones management groups should be moved to separate file as I want skip those Corp and Online MGs.
• There should be option for top level MG suffix (as we use mg-alz as prefix and mg-alz-root as root MG).
• There should be option for top level MG parent as other why -WhatIf deployment will every time show that there is changes available.

Question/Feedback

No need to copy full repo, you can simply copy infra-as-code/bicep folder. PR will be created to add Deploying ALZ-Bicep Pre Requisites

Possible Answers/Solutions?

#Copy only IaC
#Requires Git Version 2.25 or newer git --version
git clone --no-checkout https://github.com/Azure/ALZ-Bicep
cd ALZ-Bicep
git sparse-checkout init --cone
git sparse-checkout set infra-as-code/bicep

Describe the solution you'd like

Currently hub network modules deploy bastion subnet AzureBastionSubnet without NSGs. The AzureBastionSubnet subnet supports NSGs and it is a Well-Architected Framework (WAF) recommendation to deploy all subnets with NSGs. No specific exclusion applies for AzureBastionSubnet.

Requirements for Bastion NSG is here: https://docs.microsoft.com/azure/bastion/bastion-nsg#nsg

See:

• https://docs.microsoft.com/azure/architecture/framework/security/design-network-segmentation
• https://docs.microsoft.com/azure/security/fundamentals/network-best-practices#logically-segment-subnets

Additional context

This is reported by PSRule for Azure: https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.VNET.UseNSGs/

Related to #206

Describe the bug

custom-policy-definitions.bicep calls loadTextContent multiple times for the same file. This causes the content of the file to be put into the output file multiple times which bloats the file significantly

To Reproduce

Steps to reproduce the behaviour:

1. Build a bicep file that uses custom-policy-definitions.bicep and take not of the size of the output file
2. Manually replace the redundant calls to loadTextContent in custom-policy-definitions.bicep by using a var instead
3. Build the new bicep file and take note of the size of the output file

Expected behaviour

custom-policy-definitions.bicep should only load each file it needs one time and store the content in a var to prevent file bloat

Screenshots 📷

Good example

Note the definitionParameters in each of the examples

var publicPaasEndpointsParams = json(loadTextContent('lib/policy_set_definitions/policy_set_definition_es_deny_publicpaasendpoints.parameters.json'))

... other stuff removed for clarity

libSetChildDefinitions: [
      {
        definitionReferenceID: 'ACRDenyPaasPublicIP'
        definitionID: '/providers/Microsoft.Authorization/policyDefinitions/0fdf0491-d080-4575-b627-ad0e843cba0f'
        definitionParameters: publicPaasEndpointsParams.ACRDenyPaasPublicIP.parameters
      }
      {
        definitionReferenceID: 'AFSDenyPaasPublicIP'
        definitionID: '/providers/Microsoft.Authorization/policyDefinitions/21a8cd35-125e-4d13-b82d-2e19b7208bb7'
        definitionParameters: publicPaasEndpointsParams.AFSDenyPaasPublicIP.parameters
      }

Bloated Example (code today)

libSetChildDefinitions: [
      {
        definitionReferenceID: 'ACRDenyPaasPublicIP'
        definitionID: '/providers/Microsoft.Authorization/policyDefinitions/0fdf0491-d080-4575-b627-ad0e843cba0f'
        definitionParameters: json(loadTextContent('lib/policy_set_definitions/policy_set_definition_es_deny_publicpaasendpoints.parameters.json')).ACRDenyPaasPublicIP.parameters
      }
      {
        definitionReferenceID: 'AFSDenyPaasPublicIP'
        definitionID: '/providers/Microsoft.Authorization/policyDefinitions/21a8cd35-125e-4d13-b82d-2e19b7208bb7'
        definitionParameters: json(loadTextContent('lib/policy_set_definitions/policy_set_definition_es_deny_publicpaasendpoints.parameters.json')).AFSDenyPaasPublicIP.parameters
      }

Correlation ID

A correlation ID really helps us investigate your issue further. Please provide one if possible. Details on how to find a correlation ID can be found here: Correlation ID and support

Additional context

Anything else we should know to help us troubleshoot this bug? I have created a separate but highly related issue on the bicep side here Azure/bicep#6970

Describe the solution you'd like

Use latest API versions in all modules as per #245

Module List

Scroll right and left

Additional context

cc: @olljanat for awareness

Describe the solution you'd like

Picked up from https://github.com//issues/244#issuecomment-1137199634

I see that ability to be able to run pull requests with WhatIf mode against of production is very critical as other why it is not possible to have GIT repo with CI to production and multiple persons contributing to code without high risk to break things.

That why pull request validation here should contains following steps for all modules:

1. Deploy
2. Deploy again with WhatIf mode
3. Check output from WhatIf to make sure that it does not find differences between code and environment.

Tricky part is long list of known issues listed on https://aka.ms/WhatIfIssues which can be only fixed by Microsoft.

Status per module:

Describe alternatives you've considered

I really don't see good alternatives for this.

Additional context

I did drop cleaned copy of my draft solution about how to use ALZ-Bicep with Azure DevOps CI to https://github.com/olljanat/alz-bicep-ci and it already contains WhatIf verification for pull requests on those parts which I have got working.

Describe the bug

The Markdown Link Checker is Failing on some microsoft.com URIs, see a recent run from a PR here: https://github.com/Azure/ALZ-Bicep/runs/6418774058?check_suite_focus=true

URIs impacted:

• https://www.microsoft.com/trustcenter
• https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general
• https://www.microsoft.com/en-us/msrc/pgp-key-msrc
• https://www.microsoft.com/msrc
• https://microsoft.com/msrc/bounty
• https://www.microsoft.com/en-us/msrc/cvd

To Reproduce

Create any PR that triggers the code-review.yml action

Expected behaviour

No errors as these links are fine

Describe the solution you'd like

Add configuration of VWAN Route Table in VWAN If Deploying Azure Firewall in Secure Hub Model

Describe alternatives you've considered

N/A

Additional context

N/A

Describe the bug

Missing step by step instructions on how to create virtual network peerings using the virtualNetworkPeer module.

To Reproduce

Steps to reproduce the behaviour:

1. Go to https://github.com/Azure/ALZ-Bicep/tree/main/infra-as-code/bicep/modules/virtualNetworkPeer.
2. In the Readme review the Deployment section
3. It says Module is intended to be called from other modules as a reusable resource, which is not really sufficient for deployment.

Expected behaviour

A clear and concise description of how to deploy virtual network peerings using az cli and Powershell in Azure Public and Azure China.

Screenshots 📷

Correlation ID

N/A

Additional context

Since this is described for other core modules including vWan network connection module, it should also be described here.

Question/Feedback

I notice that location linter warning is disabled for certain modules and it's unclear why these should be.

Generally, ignoring linter warnings can lead to poor code quality so trying to understand when one should disable linter rules like this and when to resolve them.

Example: https://github.com/Azure/ALZ-Bicep/blob/main/infra-as-code/bicep/modules/hubNetworking/hubNetworking.bicep

module modCustomerUsageAttribution '../../CRML/customerUsageAttribution/cuaIdResourceGroup.bicep' = if (!parTelemetryOptOut) {
  #disable-next-line no-loc-expr-outside-params
  name: 'pid-${varCuaid}-${uniqueString(resourceGroup().location)}'
  params: {}
}

Describe the bug

I found two inconsistencies in the Hub Networking module. Two specific parameters are declared in the hubNetworking.bicep template, but they are not present in the hubNetworking.parameters.example.json nor in the documentation on Wiki:

• parNetworkDNSEnableProxy
• parDisableBGPRoutePropagation

Since both parameters have default values set in the template, this bug doesn't prevent a successful module deployment. It is just a matter of consistency 🙂

Provide flexibility in the Management group hierarchy by defining structure in a parameter file. This would potentially address this issue #158 in providing more flexibility in how/which Management groups get deployed.

Additionally, it may be beneficial to include Subscription to Management Group assignments in this single deployment as well.

Describe the bug

Sidebar in wiki is linking incorrectly on the ACR link. Shows raw.github...... instead of nicely formatted wiki page

To Reproduce

Steps to reproduce the behaviour:

1. Browse to wiki
2. Click on ACR link on the sidebar

Expected behaviour

Nicely formatted ACR wiki page displayed instead of raw

Screenshots 📷

N/A

Correlation ID

N/A

Additional context

Nope

I followed the documentation without using the parameters file, the 'logging.bicep' module failed in the last step which is linking automation account to the log analytics workspace. The parameter for automation account uses 'resourceGroup().location as default value, also our steps uses 'eastus' as location while creating the resource group. This is leading to the error in the last step.

Can we update our documentation to have default value for Automation account location as one of the supported regions, may be eastus2 (this is exist in parameters file, but users who are trying without parameter end up an error because of the default value)?

Can we also introduce an allowed list that restrict the locations only to the supported regions?

Question/Feedback

I noticed that e2e tests have been moved to Azure DevOps on some point. However for me it looks that those are now hosted on project which type is "Private".

Possible Answers/Solutions?

As this is open source project it would be nice if project type "Public" can used on that Azure DevOps project side too so pipeline definitions and build results would be visible on here too.

Question/Feedback

First of all, it's great to see the work you have done in the area of ALZ. It's an area we are actively working on at the organisation I work for.

I'm interested in your thoughts around the development lifecycle and versioning strategy for BICEP module engineering.

We have been following publish bicep modules to ACR with azure devops with interest and have been prototyping using Nerdbank as mentioned in the thread. Will you be aligning to the outcomes from the work in relation to the MSFT public repo?

I guess it would also help to understand the ACR tagging strategy too - module development versus module release.

Would like to know the roadmap for the ALZ bicep repo. Is this a proof of concept or capability which you are going to further build upon? Are you going to add more modules and features in the future releases?

This does not work with Virtual Hubs, it appears the Public IP is a read only resource that gets randomly allocated?

Question/Feedback

would you please to explain the logic behind policy deployment/assignment.
this issue is inspired by twitter post

Possible Answers/Solutions?

• big picture of policy deployment principles
• elaborate on the deployment telemetry
• what is the meaning of _policyDefinitionsBicepInput.txt file under /modules/policy/definitions/lib

As documented in our Contributing wiki page (also shown in the table below) we follow the Hungarian notation naming pattern for our symbolic names in all our code and modules.

Current Naming Pattern - Hungarian Notation

Reasons why we did this

1. Easier for those new to Infra-as-Code the understand where to find things and navigate the links/dependencies/references in the code base
2. Doesn't require any tooling or extensions to be installed to navigate code
   • Useful in things like Pull Request reviews where no IDE and tooling is generally used
3. Bicep language does not state we shouldn't use this pattern
4. Keeps it close to ARM where you would have the type defined in references like "[parameter('region')]"
5. Better than having no naming standard at all 😎

** WE WANT YOU TO HELP US DECIDE THE FUTURE AND VOTE (SEE BELOW) **

Whether you agree and like the use of Hungarian notation or not, we want you to vote on this form to let us know either way: https://forms.office.com/r/Ppu2z6kfvq

(make sure you log your vote even if you are a fan and do like the use of Hungarian notation. As if we only get responses from users who don't like it or poll will be unfairly biased 😊)

Also feel free to leave comments below if you want to 👍

Describe the solution you'd like

The current release (0.1.0) only supports the Traditional Networking ALZ topology.

It would be great to have a feature parity with the Portal-based experience and enable the second networking model based on Azure Virtual WAN.

Describe the solution you'd like

Add note to Custom Policy Definitions README to point to the default Policy Assignments to make it easier for users to navigate

Describe the solution you'd like

Add reference to hubPeeredSpoke orchestration module in docs

• Deployment Flow Wiki docs

Describe alternatives you've considered

N/A

Additional context

N/A

Describe the solution you'd like

Since bicep cannot delete deployed Policy-Definitions, Policy-SetDefitnitions or Assignments, we need a way to maintain deployed Policies. Example: We assign a Policy with the ALZ-Bicep code. Now we want to remove this assignment again.

Describe alternatives you've considered

Manual or PowerShell removing is needed. But also cleaning bicep code as well.

@jtracey93

Describe the solution you'd like

Hi project maintainers and contributors.

Is it planned in the short-term roadmap to advance the CI/CT/CD for ALZ?

Before Bicep files&modules are merged into main branch (and then ACR), they should be validated with PSRule for Azure. This ensures that ALZ code is alligned with the framework.

These rules exist across five WAF pillars.

• Cost optimization
• Operational excellence
• Performance effiency
• Reliability
• Security

Describe alternatives you've considered

Branch policy for PRs where target branch is main (ideally these problems would have surfaced earlier in the coding inner loop, but sometimes mistakes can happen and bad files can make it back into source control etc).

CRON for main as well (when main is DRY and PSRule is constant being updated to align with WAF).

Policy consists of PSRule traversing through the parameter file or Bicep directly.

All Bicep code should be checked and not only input based on the PR. PRs often tend to focus code review solely on new code. Instead of looking at code as a whole and working to improve it as such..

Additional context

Nothing in particular for now.

Describe the solution you'd like

How do you see a module for the Identity part of the ALZ concept?

The module should include these features:

• ‘All’ infrastructure management resources.
• Multiple subscriptions support.
• Multiple regions, single subscription support.
• Domain controller supported deployment (Data disk and caching settings).
• Deployment of Gen2 trusted VM(s) for domain controller role.
• Keyvault with autogenerated initial login credentials.
• Network and peering like a spoke network but for ADDS services.
• NSG protected subnet with ADDS default rules included.
• NSG protected RDP access from only trusted IP(s). PAWs, jumstations etc.
• Backup vault deployed and configured.
• Added to central Log Analytics workspace for update and OS management.
• Other infrastructure parts like tags, etc.

Describe alternatives you've considered

We will have to do this either way, so more if you see this as part of this project as an extra module?

Additional context

Feel free to reach out if we should discuss this offline.

Describe the bug

When using the virtualNetworkPeer module it is not possible to set the useRemoteGateways property on the Spoke peering configuration. This setting is missing in the 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings' resource.

To Reproduce

N/A

Expected behaviour

This should be part of module, so a fully configurable and working Hub and Spoke setup with gateways can be configured.

Screenshots 📷

N/A

Correlation ID

N/A

Additional context

PR has been created to fix this: #188

Describe the bug

Unable to run the GitHub Actions workflow
A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Cloned repository
2. Created the workflow in GitHub
3. Ran the workflow as a workflow_dispatch trigger

A clear and concise description of what you expected to happen without this bug 🙂

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Correlation ID

A correlation ID really helps us investigate your issue further. Please provide one if possible. Details on how to find a correlation ID can be found here: Correlation ID and support

Additional context

GitHub Secret:

AZURE_CREDENTIALS
{
"appId": "redacted",
"displayName": "redacted",
"password": "redactd",
"tenant": "redacted"
}

Relevant workflow file content

name: ALZ GitHub Actions deployment pipeline

on: [workflow_dispatch]

env:
ManagementGroupPrefix: "alz07"
TopLevelManagementGroupDisplayName: "Azure Landing Zones"
Location: "centralus"
LoggingSubId: redacted
LoggingResourceGroupName: "alz-logging-rgp-01"
HubNetworkSubId: redacted
HubNetworkResourceGroupName: "alz-network-hub-rgp-01"
RoleAssignmentManagementGroupId: "alz07-platform"
SpokeNetworkSubId: redacted
SpokeNetworkResourceGroupName: "spoke-networking-rgp-01"
runNumber: ${{ github.run_number }}

jobs:
bicep_tenant_deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Repo
uses: actions/checkout@v2
with:
fetch-depth: 0

  - name: Azure Login
    uses: azure/login@v1
    with:
      creds: '${{ secrets.AZURE_CREDENTIALS }}'

Describe the bug

hubNetworking - Inconsistent cases for parDDoSEnabled / parDDoSPlanName in bicep vs documentation and parameter.sample.json

Facing following error when following documentation applying parameter.example.json + parDdosEnabled

New-AzResourceGroupDeployment: 9:55:13 PM - Error: Code=CaseSensitiveDeploymentParameterNamesFound; Message=The deployment parameters are using case sensitive names. The error parameter name(s): parDDoSEnabled,parDDoSPlanName. Please see https://aka.ms/arm-keyvault for usage details.

Steps to reproduce the behaviour:

Follow documentation and overwrite parDdosEnabled parameter (following case in hubNetwork doc page)

New-AzResourceGroup -Name $varConnectionRG
-Location $varDeplRegion

[bool] $varDdosEnabled = 0

New-AzResourceGroupDeployment -TemplateFile infra-as-code/bicep/modules/hubNetworking/hubNetworking.bicep
-TemplateParameterFile infra-as-code/bicep/modules/hubNetworking/hubNetworking.parameters.example.json -parDdosEnabled $varDdosEnabled
-ResourceGroupName $varConnectionRG

New-AzResourceGroupDeployment: 7:32:57 AM - Error: Code=CaseSensitiveDeploymentParameterNamesFound; Message=The deployment parameters are using case sensitive names. The error parameter name(s): parDdosEnabled. Please see https://aka.ms/arm-keyvault for usage details.

New-AzResourceGroupDeployment: The deployment validation failed

Expected behaviour

No error :-)

Screenshots 📷

NA

Correlation ID

NA

Additional context

Based on my investigation, I can see the mismatch in the
hubNetworking.bicep> parDDoSEnabled
hubNetworking.parameters.example.json> parDdosEnabled
Documentation> parDdosEnabled

Similar inconsistency for parDDoSPlanName / parDdosPlanName

The error trigger only if we use Bicep parameter and -TemplateParameterFile together.

Solution > Align casing - I could do it but I am not sure how to interpret the camelCase rules so I let to the experts.

Describe the bug

If you do not have a Ddos protection plan setup in Azure and set the parDdosProtectionPlanId parameter in alzDefaultPolicyAssignments.bicap to an empty string you still have the Virtual networks should be protected by Azure DDoS Protection Standard policy assignment set and enabled. This causes the following error when trying to re-deploy the hub network template:

ERROR: {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n \"error\": {\r\n \"code\": \"LinkedInvalidPropertyId\",\r\n \"message\": \"Property id '' at path 'properties.ddosProtectionPlan.id' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}' or '/providers/{resourceProviderNamespace}/'.\"\r\n }\r\n}"}]}}

You get this error when trying to deploy a spoke:

ERROR: {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"Conflict","message":"{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n \"details\": [\r\n {\r\n \"code\": \"DeploymentFailed\",\r\n \"message\": \"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.\",\r\n \"details\": [\r\n {\r\n \"code\": \"BadRequest\",\r\n \"message\": \"{\\r\\n \\\"error\\\": {\\r\\n \\\"code\\\": \\\"LinkedInvalidPropertyId\\\",\\r\\n \\\"message\\\": \\\"Property id '' at path 'properties.ddosProtectionPlan.id' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}' or '/providers/{resourceProviderNamespace}/'.\\\"\\r\\n }\\r\\n}\"\r\n }\r\n ]\r\n }\r\n ]\r\n }\r\n}"}]}}

To Reproduce

Steps to reproduce the behaviour:

1. Set the parDdosEnabled parameter in hubNetworking.bicep to false (this may not be relevant to the issue but I have it set this way)
2. Set the parDdosProtectionPlanId parameter in alzDefaultPolicyAssignments.bicep to an empty string.
3. Deploy the policy assignment template.
4. (re)deploy the hubNetworking template and/or (re)deploy the spokeNetworking template.

Expected behaviour

With parDdosEnabled set to false, and the parDdosProtectionPlanId set to an empty string I would not expect the policy to be assigned.

Correlation ID

Hub deployment: 4f412669-a92c-413b-b017-adcbb3f8ab68
Spoke deployment: 873ccc68-d142-4b63-87bd-5fca9f01291c

Additional context

Setting the Virtual networks should be protected by Azure DDoS Protection Standard policy assignment enforcement to disabled stops the error from happening on both the hub and spoke template deployments.

Describe the solution you'd like

Add deployment name to all cli snippets as well as faq q&a about benefits of uniqueness for deployment history. Also include links to auto cleanup.

Describe alternatives you've considered

N/A

Additional context

Deployment names should be unique to enable tracking and deployment history to be useful.

Using time/date in the name is not the best approach instead a unique string generated from something like date/time and other inputs to keep deployment names short enough to deploy successfully still.

Please clarify or provide pointers for the below issues / feature requests:

1. Presently there is no single bicep file which can be called upon to deploy full Infra. Am looking at something like a main.bicep file that would call the child modules from their respective trees. It will be consumed with / without looping in the main.bicep file as per requirement. It will also have single mainparameter.json file.
2. If these were modularized, they could have been consumed to create one or multiple resources as per need. Looping is missing for some modules.
3. Also the modular approach missing and creation of different types of resources happening in a single massive bicep file like hubNetworking.bicep.
4. Scenario such as deploying multiple resource at parent and then deploy corresponding child resources within those deployed parent resources. It was interesting to see how you would have approached it. e.g. Create 2 Log Analytics Workspace with 1st LA workspace getting 3 different solutions and the 2nd LA workspace deployed with some other solutions.

Describe the solution you'd like

Add tags to hub virtual network

Describe alternatives you've considered

N/A

Additional context

N/A

Describe the solution you'd like

Change SuperLinter to only run on changed docs

Describe alternatives you've considered

None

Additional context

As discussed on a recent internal sync call, we all agree this is too slow scanning everything now so would prefer it only scans the changed docs

Describe the solution you'd like

Support for tagging on the resource group creation process and on central logging deployment for components like log analytics workspace and automation account.

Describe alternatives you've considered

Can be done by an after deployment script, or tags maintain script, but not a great solution.

Additional context

Add any other context or screenshots about the feature request here. 📷

Maybe change the advisory at this line

To the built-in option:
Inside User Settings:
Editor › Bracket Pair Colorization: Enabled
or
Inside User Settings (JSON):
"editor.bracketPairColorization.enabled": true

This prevents another extension to be installed, native stuff tends to work usually 🤓

Also maybe looke at ms-azure-devops.azure-pipelines as an advisory :) ?