search

Azure / Enterprise-Scale

The Azure Landing Zones (Enterprise-Scale) architecture provides prescriptive guidance coupled with Azure best practices, and it follows design principles across the critical design areas for organizations to define their Azure architecture
https://aka.ms/alz
MIT License
1.69k stars 963 forks source link

Issue Report - Deny vNet peering to non-approved vNets #1580

Closed gjongeneel closed 3 months ago

gjongeneel commented 7 months ago

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

1. 2.

Screenshots

gjongeneel commented 7 months ago

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 commented 7 months ago

@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 commented 3 months ago

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 commented 3 months ago

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