Feature Request - Ability to disable inbound peering about terraform-azurerm-lz-vending HOT 8 CLOSED

Hey @DevSecNinja - we are considering this: see #132

from terraform-azurerm-lz-vending.

Thanks @DevSecNinja will close in favor of #132

from terraform-azurerm-lz-vending.

Seems a fair ask @DevSecNinja ... Will discuss with @matt-FFFFFF to see what we can do to help 👍🏻

from terraform-azurerm-lz-vending.

Hi @DevSecNinja

I'm happy to investigate this change.

Please can you share how you are establishing this in config? The reason we create both hub peerings with the LZ vending module is that the subscription ID (and therefore resource ID of vnet) is not known until after the sub alias resource has been created. Therefore it made sense to us to leave the peering configuration to the lz-vending module. Can you provide a sample of how you have this wired up? Have you used the outputs of the lz-vending module to populate the list of spoke_virtual_network_resource_ids? If so how have you ensured the vnets are peered to the correct hub?

Furthermore, in terms of privileges. I have seen a custom role used that is only able to manage peerings for the hub network. We document the required permissions here: https://learn.microsoft.com/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal#permissions

from terraform-azurerm-lz-vending.

Thanks @matt-FFFFFF! Sure, I've added the VNET IDs statically to spoke_virtual_network_resource_ids in the CAF module with a comment to 'prettify' that. (It's a small test environment) I have my subscription IDs and names in a separate JSON file, so I should be able to use that as input. But it's not as nice.

Can the vending module also provision the Private DNS resources that are provisioned when using spoke_virtual_network_resource_ids in the CAF module? If yes, that would convince me to move the peering over to the vending module.

Thanks!

from terraform-azurerm-lz-vending.

Hey @DevSecNinja - we are considering this: see #132

Thanks for creating that! But doesn't that introduce the same 'challenges' as what we have now with this inbound/outbound peering situation? As in, we need to keep track of something (either created VNETs or private DNS zones) that comes from the other module? In this case, the Private DNS zones that are created in the ES CAF module and VNET linked to the spoke VNET from the vending module.

Not sure which approach I like more. What do you think?

from terraform-azurerm-lz-vending.

Good point!

The CAF ES module provides outputs for all created resources, including the hub network resource ID in order to create the peering in the first place 😄

In terms of order of operations, we see that the platform would be created first. Therefore the vnet and pDNS zone resource IDs are already known.

In terms of the subs that are created by LZ vending, out assumption is that these subscriptions should be created afterwards.

If the modules exist in the same state, or if the LZ vending module can access the state of the ES CAF module, then the resource IDs for the hub resources can be mapped into the lz vending module.

We document how to do this here: https://github.com/Azure/terraform-azurerm-lz-vending/wiki/Example-4-Integration-with-ALZ-module#locals

Does this work @DevSecNinja?

from terraform-azurerm-lz-vending.

Thanks @matt-FFFFFF, in combination with the private DNS linking that could work!

from terraform-azurerm-lz-vending.