Feature Request for vending module subnet creation

[chanakanissanka]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

We are currently using vending module parallel to this repo as our vending machine. With the vending module, we are using our native subnet creation codes as we don't have subnet creation capability with Vending. This request is to check the possibility of doing that using this repo or any other way we are unaware of.

Is your feature request related to a problem?

No, This not related to a problem

Describe the solution you'd like

May be an example that will include creating subnets for a vended out spoke vnet leveraging this code base?

Additional context

[matt-FFFFFF]

Moving issue to lz-vending repo

[matt-FFFFFF]

Hi @chanakanissanka

We excluded subnets from this module as we felt that it would be the application team that would provision their own. This and the complexity of the subnet resource could make the inputs unwieldy.

However it's fairly simple to use the module's outputs to create subnets. Can you describe more about your scenario, for example how are you calling the LZ vending module? Do you use for_each?

[chanakanissanka]

Thanks for your reply. Yes, it does make sense about your approach.
Atm, we are using vending module only for Networking Capability. We do not use it for sub-creation, mgmt replacement, or role assignments. It would be nice to use them at some point, though.

Yes, we use for_each and by calling out vending module with the following parameter alongside our development of it.

networks = {
vnet1 = {
name = "spoke_1"
address_space = ["x.x.x.x/y"]
resource_group_name = "rg-networking"
hub_peering_enabled = true
hub_peering_use_remote_gateways = false
hub_network_resource_id = ""
subnets = {
subnet1 = {
name = "test"
cidr = ["REPLACEME"]
# service_endpoints = ["Microsoft.ServiceBus"]
}
subnet2 = {
name = "AzureFirewallSubnet"
special_subnet = true #special_subnet means NO nsg will be created for this subnet
cidr = ["REPLACEME"]
}
}
}
vnet2 = {
name = "spoke_2"
address_space = ["z.z.z.z/y"]
resource_group_name = "rg-networking"
hub_peering_enabled = true
hub_peering_use_remote_gateways = false
hub_network_resource_id = ""
subnets = {}
}
}
This approach is working fine. The missing part where we have to do quite a bit of development is NSG and UDR,
Are there any plans or backlog items to add those capabilities with Vending Module, or is it for the application team, as you mentioned?
TIA,

[matt-FFFFFF]

We have considered NSG but feel that the security admin rules feature of Azure Virtual Network Manager is better aligned to this: https://learn.microsoft.com/en-us/azure/virtual-network-manager/concept-security-admins

In terms of UDR, we have thought of adding the deployment of a 'default' NSG that will forward all traffic to a defined IP address. The issue is that this cannot be assigned to subnets, as we do not create them.

[chanakanissanka]

Thanks for the update.
In an ideal scenario, we believe that, we need to control NSG and UDR for this vending. 'We' as in platform team in Level3. Application team need to provide a PR for changing NSG and UDR. This way we have a control over what plumbed in for the hub/core. On top of that, they can have as much as they want as part of their deployments.

Coming back to our discussion agreed with this approach as it makes perfect sense, -#206 (comment).

re : UDR - as explained above we are creating the subnets and it's sits in our state. This may be specific to our approach. The only reason for this approach is we don't want to offload subnet creation to app teams as it can leads to governance issues like CIDRs usage.

[matt-FFFFFF]

closing and tracking in #218