Azure CLI for Postgress Flexible server add default VNET range on an existing VNET

[rackalex]

Describe the bug

When running an ''az postgres flexible-server replica create" with specificing the snet as an resource Id we have experience, that the command itself has updated an existing VNET with the Default prefix, specified in the default value (see: https://github.com/Azure/azure-cli/blob/main/src/azure-cli/azure/cli/command_modules/rdbms/flexible_server_virtual_network.py) . This behavoir (as you can imagine) can create a big impact on the overall network infrastructure in an enterprise Azure environment. We would like to the feedback:

• why this behavior occurred?
• what can we do to prevent 'az postgres flexible-server replica create' to add the default range of 10.0.0.0/16 to an exisitng VNET?

Related command

Command executed:

az postgres flexible-server replica create --resource-group some-rg --replica-name some-name --source-server somename --private-dns-zone postgress-zone-id --subnet subnet-resource-id --yes

WARNING: You have supplied a Subnet ID. Verifying its existence...
WARNING: Using existing Vnet "VNET-SOME-NAME" in resource group "RSG-SOME-NAME"
WARNING: The address prefix does not exist in the Vnet. Adding address prefix 10.0.0.0/16 to Vnet VNET-SOME-NAME.
WARNING: Using existing Subnet "SNET-SOME-NAME" in resource group "RSG-SOME-NAME"
WARNING: Using the existing private dns zone privatelink.postgres.database.azure.com in resource group "RSG-SOME-NAME"

Errors

The existing VNET was modified and the address prefix 10.0.0.0/16 was added and created routing issue for the complete network topologie

Issue script & Debug output

Command executed:

az postgres flexible-server replica create --resource-group some-rg --replica-name some-name --source-server somename --private-dns-zone postgress-zone-id --subnet subnet-resource-id --yes

WARNING: You have supplied a Subnet ID. Verifying its existence...
WARNING: Using existing Vnet "VNET-SOME-NAME" in resource group "RSG-SOME-NAME"
WARNING: The address prefix does not exist in the Vnet. Adding address prefix 10.0.0.0/16 to Vnet VNET-SOME-NAME.
WARNING: Using existing Subnet "SNET-SOME-NAME" in resource group "RSG-SOME-NAME"
WARNING: Using the existing private dns zone privatelink.postgres.database.azure.com in resource group "RSG-SOME-NAME"

Expected behavior

If the VNET exists, it should not add the default vnet range to it.

Environment Summary

azure-cli 2.51.0 *

core 2.51.0 *
telemetry 1.1.0

Dependencies:
msal 1.24.0b1
azure-mgmt-resource 23.1.0b2

Additional context

No response

[azure-client-tools-bot-prd]

Hi @rackalex,

2.51.0 is not the latest Azure CLI(2.73.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[github-actions]

This issue is related to security. Please pay attention.

Powered by issue-sentinel

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @gbowerman, @jasomaning, @nachoalonsoportillo.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @gbowerman, @jasomaning, @nachoalonsoportillo.

[rackalex]

I will update az cli - but nevertheless. the VNET in that particular situation was definitely there (it has 100s of workloads connect). Was this a intermediate API issue?

[nachoalonsoportillo]

@rackalex Thanks for hainvg reported this issue to us. Sorry for not having reached out before, but I missed this one. Have been looking into it today and we're considering to pull off our module all the current create or update operations it implicitly do on the private DNS zone, VNet or subnet resources. Most probably, we'll simplify the interface to the az postgres flexible-server replica command, and will limit the functionality to read only operations used to validate that passed resources exist and are configured as per our service requirements. Obviously, for a change like this, we'll announce corresponding breaking changes first and then change current behavior in a later version of CLI.