[Feature Request]: Add RoutingIntent child module to Virtual Hub module.

[annduda]

Description

Hi,

Could we have a routing Intent functionality for virtual Hub which would allow sending traffic to Azure Firewall:
https://learn.microsoft.com/en-us/azure/templates/microsoft.network/virtualhubs/routingintent?pivots=deployment-language-bicep

resource symbolicname 'Microsoft.Network/virtualHubs/routingIntent@2023-02-01' = {
  name: 'string'
  parent: resourceSymbolicName
  properties: {
    routingPolicies: [
      {
        destinations: [
          'string'
        ]
        name: 'string'
        nextHop: 'string'
      }
    ]
  }
}

[AlexanderSehr]

Hey @annduda,
we sure can. I'll move the issue into the 'todo' state. Feel free to implement and contribute it yourself if you have the capacity. If not, we'll see to have it implemented by a member of the community :)

[annduda]

Hey @AlexanderSehr if nobody took it yet I can try :)

[AlexanderSehr]

If you have the capacity, please do - and if you need support, please let me know :)

[AlexanderSehr]

Hey @arnoldna ,
I just migrated this issue over from CARML. Please take a look and triage if still relevant :)

[ericscheffler]

Working on this now

[ericscheffler]

Running in to an issue with integrating this functionality; the problem is that this feature requires a firewall (Azure Firewall, for example), to be created and associated with the virtual hub before it is invoked, otherwise it will error out with an "invalid next hop" condition. In order for the firewall to be properly associated to the hub, it has to be created after the virtual hub, since the hub.id needs to be specified during the firewall creation (confirmed with the VWAN PG that providing the firewall.id during hub creation does nothing; it is a read-only parameter). The deployment flow needs to be:

• Create the hub
• Create the firewall (passing in hub resource id)
• Invoke routing intent config

The requirement for a firewall effectively introduces a race condition; @ChrisSidebotham is going to discuss amongst the core team how to approach this issue. There are a couple different courses of action under consideration:

• Leaving routing intent out of the virtual hub module and calling it from a VWAN pattern instead
• Deploying the Azure Firewall as part of the virtual hub module
• Something else?

Work is on-hold pending further direction.

[AlexanderSehr]

Hey @ericscheffler,
thank you for the elaborate description 💪. Maybe I'm simplifying this too much, but wouldn't it work to

• Implement the child module as a normal child module
• Implement a test that creates a plain VirtualHub & Firewall in its dependencies - and then invoke the module in an idempotent way with the routing intent defined as a parameter

I did something similar for some CMK tests where I wanted to show how to do this with a System-Assigned identity. Similar issue: How to assign permissions to a MSI if the MSI is only created after the service is deployed for which I want to define CMK. Same solution: Deployed the vanilla service with a system-assigned identity in the test's dependencies, set the permissions, then invoked the module like nothing happened in an idempotent way. For reference: https://github.com/Azure/bicep-registry-modules/blob/main/avm/res/cognitive-services/account/tests/e2e/system-assigned-cmk-encryption/main.test.bicep