[AVM Module Issue]: Subnet NetworkSecurityGroup association is not applied

[kmosti]

Check for previous/existing GitHub issues

• [X] I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/network/virtual-network

(Optional) Module Name if not listed above

No response

(Optional) Module Version

0.1.5

Description

When applying the following modules, the subnet is NOT updated with the nsg ID:

param VNET object = {
  name: 'microservices-vnet'
  prefixes: ['10.8.0.0/16']
  subnets: [
    {
      name: 'microservices-snet'
      prefix: '10.8.0.0/27'
    }
  ]
}

module modExternalVNET 'br/public:avm/res/network/virtual-network:0.1.5' = {
  name: '${uniqueString(deployment().name)}-vnet'
  scope: resourceGroup()
  params: {
    name: VNET.name
    addressPrefixes: VNET.prefixes
    subnets: [
      for snet in VNET.subnets: {
        name: snet.name
        addressPrefix: snet.prefix
        networkSecurityGroupId: '/subscriptions/redacted/resourceGroups/microservices-rg/providers/Microsoft.Network/networkSecurityGroups/microservices-nsg'
        delegations: [
          {
            name: '${snet.name}-del'
            properties: {
              serviceName: 'Microsoft.Web/serverFarms'
            }
          }
        ]
        serviceEndpoints: [
          {
            service: 'Microsoft.KeyVault'
          }
          {
            service: 'Microsoft.Storage'
          }
          {
            service: 'Microsoft.Web'
          }
        ]
      }
    ]
  }
}

When I apply the same resources this way (without using avm), the subnet IS updated with the correct NSG id:

param nsgName string = 'microservices-nsg'
param vnetName string = 'microservices-vnet'
param subnetName string = 'microservices-snet'

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' existing = {
  name: nsgName
}

resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' existing = {
  name: vnetName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-09-01' = {
  name: subnetName
  parent: vnet
  properties: {
    addressPrefix: '10.8.0.0/27'
    networkSecurityGroup: {
      id: nsg.id
    }
    serviceEndpoints: [
      {
        service: 'Microsoft.KeyVault'
      }
      {
        service: 'Microsoft.Storage'
      }
      {
        service: 'Microsoft.Web'
      }
    ]
    delegations: [
      {
        name: '${subnetName}-del'
        properties: {
          serviceName: 'Microsoft.Web/serverFarms'
        }
      }
    ]
  }
}

There are no errors or failures in my deployment logs, the subnet is just not updated with the specified network security group.

(Optional) Correlation Id

No response

[microsoft-github-policy-service[bot]]

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[!NOTE] This label was added as per ITA06.

[github-actions[bot]]

@kmosti, thanks for submitting this issue for the avm/res/network/virtual-network module!

A member of the @azure/avm-res-network-virtualnetwork-module-owners-bicep or @azure/avm-res-network-virtualnetwork-module-contributors-bicep team will review it soon!

[microsoft-github-policy-service[bot]]

[!NOTE] The "Type: Bug :bug:" label was added as per ITA21.

[elbatane]

Hi @kmosti , thank you for reporting the bug. We will review it and come back as soon as possible. Thanks

[rodney-almeida]

@kmosti Not sure if this was a change in the last version but the nsg reference is now called networkSecurityGroupResourceId not networkSecurityGroupId

[AlexanderSehr]

Thanks for the callout @rodney-almeida, I also just checked. It's like he says, the parameter of the module is called networkSecurityGroupResourceId. Unfortunately, the corresponding User-defined-type is not yet implemented which is why Linter did not warn you. Please double-check on your end and close the issue if it works for you :)

cc: @elbatane

[elbatane]

Hi @kmosti, as @rodney-almeida mentioned and @AlexanderSehr confirmed, the parameter is called networkSecurityGroupResourceId instead of networkSecurityGroupId, which was the parameter name you were using. Please confirm on your end to close the issue. Thank you very much.

[kmosti]

I can confirm, thank you very much for your help