Subnet definition does not match project

[fmms]

Hi,

in the bastion template we have:

data-management-zone/docs/reference/bastionhost/main.bicep

Line 31 in 73e450a

param bastionSubnetAddressPrefix string = '10.1.10.0/24'

However, in the configuration at

data-management-zone/infra/params.dev.json

Line 21 in 73e450a

"value": "10.0.0.0/16"

an address range is referenced that does not fit to this default IP address.

As the bastion host is stored in this repository to be instantiated as part of the mangement zone i suggest to get that aligned.

regards

[fmms]

Unfortunately linked to Azure/azure-quickstart-templates#2786 as well, if the solution should be redeployable.

[marvinbuss]

Thanks @fmms for submitting this.

We are calling out here that this can be deployed to a Landing Zone or Management Zone. The default subnet address prefixes are actually within the address space of the default Data Landing Zone values. Hence, this will most likely stay as it is. Users can update the address space accordingly to land this into their management zone.

Azure/azure-quickstart-templates#2786 is a well known issue that is not in control of our team. Hence, we also have to live with that network RP design. If you want to make it idempotent, you will have to add the Bastion Host template to the landing zone or management zone setup. Currently, we are evaluating whether we should do this. Please add your comment here, if you want us to work on this: Azure/data-landing-zone#202
Reason why we have not done this so far is that most customers do not require a Bastion Host, because they already have a VPN or ExpressRoute connectivity that allows them to connect to services privately. Adding a Bastion host setup in those scenarios would just consume additional address space and is therefore not desired.

[fmms]

@marvinbuss yes, i did read that it can be instantiated in both, just had the feeling as this is stored in the data-management-zone repo, it should be by default aligned to that and not the data-landing-zone. Moreover, to me it seemed like logically this should be part of the management zone as this is an overarching service while testing this and not something to be used in production scenarios where you will have network peering.

[marvinbuss]

Due to the IAM requirements described here Azure Bastion is not necessarily an overarching service that is shared across all spokes. Due to these restrictions, users often deploy this into the respective spoke rather than use it as a shared resource. As a result, we are not dictating the use and deployment only in the Management Zone or Landing Zone. It can be landed into each one of them depending on the user group.

[marvinbuss]

I will convert this into a discussion for now. If changes are required based on the discussion, we may open a new issue.