[AVM Module Issue]: Private endpoint deployed to wrong scope

[iliyansi]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/key-vault/vault

(Optional) Module Version

0.11.2

Description

I'm using version 0.11.2 of key-vault module to deploy keyvault with private endpoint configured. Problem with that version is that private endpoint is created in the scope of main resource. In previous version private endpoints parameter is based on common-types version 0.4.0 which requires resourceGroupName and that version deploys private endpoint in correct resource group.

In current version private endpoint expects resourceGroupResourceId and when is passed still deploys in KeyVault resource group. Example script

module mainGroup 'br/public:avm/res/resources/resource-group:0.4.1' = {
  scope: subscription()
  name: 'mainGrouptestdep'
  params: {
    name: 'test01'
  }
}
module vnetGroup 'br/public:avm/res/resources/resource-group:0.4.1' = {
  scope: subscription()
  name: 'vnetGrouptestdep'
  params: {
    name: 'rgtestvnet'
  }
}
module privateGroup 'br/public:avm/res/resources/resource-group:0.4.1' = {
  scope: subscription()
  name: 'privateGrouptestdep'
  params: {
    name: 'test02'
  }
}
module vnet 'br/public:avm/res/network/virtual-network:0.5.2' = {
  scope: resourceGroup('rgtestvnet')
  name: 'vnetdeploytest'
  dependsOn: [
    vnetGroup
  ]
  params: {
    name: 'vnet01'
    addressPrefixes: ['10.0.0.0/16']
    subnets: [
      {
        name: 'private'
        addressPrefix: '10.0.0.0/24'
      }
    ]
  }
}

module sb 'br/public:avm/res/service-bus/namespace:0.11.2' = {
  scope: resourceGroup('test01')
  name: 'sbtestdep'
  params: {
    name: 'sbu01'
    skuObject: {
      name: 'Premium'
    }
    // Non-required parameters
    privateEndpoints: [
      {
        name: 'pepsbu01'
        customNetworkInterfaceName: 'nifsbu01'
        subnetResourceId: vnet.outputs.subnetResourceIds[0]
        service: 'namespace'
        resourceGroupResourceId: privateGroup.outputs.resourceId
        enableTelemetry: false
      }
    ]
  }
}

module kv1 'br/public:avm/res/key-vault/vault:0.11.2' = {
  name: 'kvtestdep01'
  scope: resourceGroup('test01')
  params: {
    name: 'kvad01'
    privateEndpoints: [
      {
        name: 'pepkva01'
        customNetworkInterfaceName: 'nifkva01'
        service: 'vault'
        resourceGroupResourceId: privateGroup.outputs.resourceId
        subnetResourceId: vnet.outputs.subnetResourceIds[0]
        enableTelemetry: false
      }
    ]
  }
}

module kv2 'br/public:avm/res/key-vault/vault:0.11.1' = {
  name: 'kvtestdep02'
  scope: resourceGroup('test01')
  params: {
    name: 'kvad02'
    privateEndpoints: [
      {
        name: 'pepkva02'
        customNetworkInterfaceName: 'nifkva02'
        service: 'vault'
        resourceGroupName: privateGroup.outputs.name
        subnetResourceId: vnet.outputs.subnetResourceIds[0]
        enableTelemetry: false
      }
    ]
  }
}

With this script final result is kv2 resource created with previous version of the module and his private endpoint is created in correct resource group e.g test02. kv1 private endpoint which uses latest version is created in test01 resource group. Latest version of service-bus module have same issue since implementation is the same for private endpoints.

(Optional) Correlation Id

No response

[avm-team-linter]

@iliyansi, thanks for submitting this issue for the avm/res/key-vault/vault module!

Important

A member of the @Azure/avm-res-keyvault-vault-module-owners-bicep or @Azure/avm-res-keyvault-vault-module-contributors-bicep team will review it soon!

[iliyansi]

Any update on this i see that other modules are implementing same scope logic which will introduce same behavior.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.