Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
iliyansi opened this issue Jan 20, 2025 · 5 comments
Open
1 task done

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

iliyansi opened this issue Jan 20, 2025 · 5 comments
Assignees
Labels
Class: Resource Module 📦 This is a resource module Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue Type: Bug 🐛 Something isn't working

Comments

@iliyansi
Copy link

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

@iliyansi iliyansi added Needs: Triage 🔍 Maintainers need to triage still Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue labels Jan 20, 2025
@microsoft-github-policy-service microsoft-github-policy-service bot added the Type: Bug 🐛 Something isn't working label Jan 20, 2025
Copy link

@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!

@avm-team-linter avm-team-linter bot added the Class: Resource Module 📦 This is a resource module label Jan 20, 2025
@github-project-automation github-project-automation bot moved this to Needs: Triage in AVM - Module Issues Jan 20, 2025
@iliyansi
Copy link
Author

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

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)!

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)!

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.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed label Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Class: Resource Module 📦 This is a resource module Needs: Immediate Attention ‼️ Immediate attention of module owner / AVM team is needed Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue Type: Bug 🐛 Something isn't working
Projects
Status: Needs: Triage
Development

No branches or pull requests

2 participants