nprokopic
commented
1 year ago I started working on this this week, got it working, I can submit a PR, the change I made is relatively small, just few properties added to VNet peering.
Also you can assign this ticket to me.
/kind feature
Describe the solution you'd like [A clear and concise description of what you want to happen.]
In AzureCluster resource we can add VNet peering from cluster's VNet to any other VNet. The current implementation creates peering with default properties.
In order to configure VPN gateway transit for virtual network peering, additional non-default VNet peering properties have to be set.
There are two gateway transit scenarios from the point of view of a CAPZ cluster, depending on where the VPN gateway is deployed:
In both scenarios, the following properties are set on VNet peering on both CAPZ and peered VNets:
Furthermore, depending on where the VPN gateway is deployed, peering on both sides has to be configured with correct Virtual network gateway option.
1. VPN gateway is deployed to the remote peered VNet
The following property is set on VNet peering in remote peered VNet:
The following property is set on VNet peering in CAPZ cluster VNet:
2. VPN gateway is deployed to the CAPZ cluster VNet
The following property is set on VNet peering in CAPZ cluster VNet:
The following property is set on VNet peering in remote peered VNet:
In order to implement this, the following VNet peering properties (from Azure SDK) should be exposed in
VNetPeeringSpec(currently CAPZ is not setting these):AllowForwardedTrafficAllowGatewayTransitUseRemoteGatewaysI'm not sure if
AllowVirtualNetworkAccessis required in order to implement hub and spoke architecture described in Azure docs here, so that one might be required as well.Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
With this implemented, it becomes possible to implement gateway transit with hub and spoke architecture, where e.g. management cluster VNet is the hub, and the workload cluster VNets are the spokes.
Deploying VPN gateway is not in the scope of this issue, as it can also be deployed independently of CAPZ and it does not have to be deployed in any Kubernetes cluster VNet at all. That being said, CAPZ deploying VPN gateway would be very useful as it would enable implementation of this and many other architectures, so I will open another issue for that and link it here.