Bug Report: Customers using Azure Portal GUI to deploy VNET's in LZ's are locked

[PieterbasNagengast]

Describe the bug Customers using Azure Portal GUI to deploy VNET's in LZ's are locked due to: Update on deny subnets without NSG & UDR policy

With this updated policy the e.g. 'Subnets should have a Network Security Group' policy option set to 'Yes' (=deny) customers are unable to deploy VNET's at ALL via the Azure Portal GUI. note: You cannot assign NSG or UDR during VNET creation in Azure Portal GUI.

Seems valid to set this policy to 'Audit-Only' in case customer only uses Azure Portal GUI…. but would imply that Subnets created without a NSG (or UDR) get non-complained instead of denied.

other example: Customers Dev or App teams who gets a Online Landing zone subscription won't be able to create a VNET using the Azure Portal GUI.

As this policy is working correctly (it does what it should do) …why isn't it possible to assign NSG's or UDR's at VNET creation time in the first place?

Note: This policy (Subnet should have NSG or UDR assigned) has been recently updated: Ref: (https://github.com/Azure/Enterprise-Scale/pull/885) and (https://github.com/Azure/Enterprise-Scale/pull/885#issue-1095472165)

Steps to reproduce

1. Deploy VNET in any subscription under 'Landingzones' Management group using Azure Portal GUI
2. Deployment fails with DisallowedByPolicy error. (Policy: Subnets should have NSG assigned and/or UDR assigned)

[jtracey93]

Thanks for raising awareness @PieterbasNagengast on this.

We did update this policy recently as there was a chance depending on how people created the VNET/Subnet that they could "avoid" the policy, so we updated it to make it "waterproof" in #885 - so this is by design 👍

I will investigate this with the portal team as we should be able to create a blank VNET still which would then unblock this scenario. And even better would be allowing users to create NSGs & UDRs at time of creation for VNET/Subnets.

[jtracey93]

Update on this still investigating with the VNET portal experience teams 👍

[PieterbasNagengast]

Great, thanx for the update! In meantime I've discussed with the customer the following workarounds:

1. Add Azure Policy Exemption for both policies: 'Subnets should have a Network Security Group' and 'Subnets should have a User Defined Route'
2. Change the PolicyRule condition on both Azure policy definitions to reflect the old-'not-so-waterproof' way. See policyRule example below.
3. remove/unassign Policy's

Customer decided to go for option 2 as this would still make Subnets without a NSG or UDR 'non-compliant' in their Azure Policy Dash.

Subnets should have a Network Security Group:

    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/virtualNetworks/subnets"
          },
          {
            "field": "name",
            "notIn": "[parameters('excludedSubnets')]"
          },
          {
            "field": "Microsoft.Network/virtualNetworks/subnets/networkSecurityGroup.id",
            "exists": "false"
          }
        ]
      },

Subnets should have a User Defined Route:

    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/virtualNetworks/subnets"
          },
          {
            "field": "name",
            "notIn": "[parameters('excludedSubnets')]"
          },
          {
            "field": "Microsoft.Network/virtualNetworks/subnets/routeTable.id",
            "exists": "false"
          }
        ]
      },

Other option could be to add a separate 'DeployIfNotExist' policy for UDR's and/or NSG's. would that be an option @jtracey93?
Parameters of the Policy could have some Default NSG rules or UDR routes. I'm More than happy to help btw

[pazdedav]

+1 on this issue.

I tried to alter the default "new Azure Virtual Network" flow and manually removed the "default" subnet but such VNet cannot be deployed via the Portal (unlike with other tools), so it cannot be used as a workaround at the moment:

[jtracey93]

Thanks @pazdedav, the workaround would be to deploy the VNET via PowerShell, CLI, or an Infra-as-Code tool like Bicep or Terraform etc.

I am in contact with the portal product group around it not allowing a blank VNET, in terms of subnets, as we speak 👍

[jtracey93]

Just an update here @PieterbasNagengast & @pazdedav, I have spoken with engineering, and this is something they are aware of and actively working on. Keep an eye out for updates (no ETA to share yet).

[jtracey93]

@PieterbasNagengast @pazdedav i have an exciting update to share with you. There is a new vNet portal creation experience that we have been testing with engineering that resolves this issue.

It is now available in preview to use via https://preview.portal.azure.com

Please test and let us know.

You should be able to create blank vNets with no subnets.

[PieterbasNagengast]

Thanks @jtracey93 for mentioning! Had a quick look and looks promising! I'm able to create blank VNET's. I'm not able to create VNET's with a NSG attached to subnet(s). wizard seems stuck on 'running validation'...?

This will, for sure, help our customers with the 'Subnets should have NSG's attached to subnets' policy enabled 👍

Would also be great to add the option to attach UDR's on subnets (for customers who are using the 'Subnets should have UDR attached to subnets' policy). On second thought, why not add the full set of properties a Subnet can have (like the 'add subnet' on an existing VNET)?

[jtracey93]

Hey @PieterbasNagengast, no worries at all.

I have just tested with subnets and new NSGs and it worked fine, im asking the PG on how best you can provide feedback etc.. (stay tuned)

Have also shared your UDR feedback too :)

But the blank VNET unblocks both scenarios as you can then create the UDRs, NSGs & NSGs once the vNet has been created

[jtracey93]

Trigger ADO Sync 1

[jtracey93]

Trigger ADO Sync 2

[jtracey93]

Closing as now unblocked