Issue Report - Deny vNet peering to non-approved vNets

[gjongeneel]

Describe the Issue In order to to create a bi-directional peering between the hub and some spokes, we have to add an array of allowed vNets (by using their resource ID) that can be peered with each other. However, this needs to include all spokes to make sure that the peering from hub to spoke (in addition to the peering from spoke to hub) can be created. Uni-directional peerings are not very useful in most cases. When all spokes are added to this policy as allowed vNets, the result is that we can still create vNets between spokes! What would be the use of this policy?!?

Steps to reproduce

Screenshots

[gjongeneel]

Or should we create a separate policy for each subscription with the corresponding vNets? So a policy for the hub subscription containing the hub + all allowed spoke vNets and for each allowed spoke a policy containing the hub + spoke vNets in that specific subscription?

[Springstone]

@gjongeneel I'm not sure I'm following the issue. We use policy to do peering in a trusted management group. Peering is between a hub and a spoke (not multiple spokes) - we don't do mesh networking. I'm not sure if you have multiple VNETs in a sub and that is the issue? We typically recommend one VNET per subscription, for obvious management benefits. Typically, this is enabled in the Corp management group. Perhaps you could provide more insights into what you are tyring to achieve?

[florianow]

hey guys,

I'am also really not sure how this policy helps? Maybe I'am completely wrong but this policy disallow also the creation of vNet without any peering? Maybe i have subscriptions with vNets wich are not facing the hub.

            "allOf": [
              {
                "field": "type",
                "equals": "Microsoft.Network/virtualNetworks"
              },
              {
                "not": {
                  "field": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings[*].remoteVirtualNetwork.id",
                  "in": "[parameters('allowedVnets')]"
                }
              },
              {
                "not": {
                  "field": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings[*].remoteVirtualNetwork.id",
                  "exists": false
                }
              }
            ]
          }

I removed the whole block because the naming "Deny vNet peering to non-approved vNets" is misleading when it also blocks the creation of vNets. I was really happy to find such a policy here in the enterprise-scale but I'am on gjongeneel site, what is the Intention of this whole policy? How helps it in productive environments?

[Springstone]

Closing this issue as there is a known platform bug impacting this policy. For details, please follow https://github.com/Azure/Enterprise-Scale/issues/1657