"App Service apps should disable public network access" breaks apps deployed to private App Service Plans without Private Endpoints

[sjwaight]

Policy failure snippet:

{
"name":"App Service apps should disable public network access",
"id":"/providers/Microsoft.Authorization/policyDefinitions/1b5ef780-c53c-4a64-87f3-bb9c8c8094ba"},
"policySetDefinition":
    {
       "name": "Public network access should be disabled for PaaS services",
"id":"/providers/Microsoft.Management/managementGroups/MG/providers/Microsoft.Authorization/policySetDefinitions/Deny-PublicPaaSEndpoints"
}

Note this seems to break Function Apps via a different policy.

{
 "name":"Function apps should disable public network access",
 "id":"/providers/Microsoft.Authorization/policyDefinitions/969ac98b-88a8-449f-883c-2e9adb123127"},
  "policySetDefinition":
   {
      "name":"Public network access should be disabled for PaaS services",
"id":"/providers/Microsoft.Management/managementGroups/MG/providers/Microsoft.Authorization/policySetDefinitions/Deny-PublicPaaSEndpoints"}

The ipSecurityRestrictions are what cannot be enabled with the above policy and the publicNetworkAccess must be set to 'Enabled' too. These two properties are required to allow access from a Virtual Network. The value below is the default value set when you enable it in the Portal. I updated the SCM property manually to copy main, but it also contains the same rule when you enable in the Portal.

resource functionApp_resource 'Microsoft.Web/sites@2022-03-01' = {
  name: appName
  location: location
  kind: kind
  identity: {
    type: 'SystemAssigned'
  }
  tags: tags
  properties: {
    serverFarmId: appServiceResourceId
    // required for direct access from a Virtual Network
    publicNetworkAccess: 'Enabled'
    siteConfig: {
      appSettings: appSettings
      netFrameworkVersion: workerVersion
      // required for direct access from a Virtual Network
      publicNetworkAccess: 'Enabled'
      vnetRouteAllEnabled: vnetIntegrated
      alwaysOn: true
      ipSecurityRestrictions: [
        {
            ipAddress: 'Any'
            action: 'Allow'
            priority: 2147483647
            name: 'Allow all'
            description: 'Allow all access'
        }
    ]
    scmIpSecurityRestrictionsUseMain: true
    }
    httpsOnly: true
  }
}

Reproduction scenario:

1. Enable Policy for Subscription
2. Deploy Private ASE + ASP (with properties to meet Policy + VNet Integration + DNS). You receive 1 private IP for the ASE. This is the IP for any app / scm endpoint you later deploy,
3. Deploy Logic App with properties to meet Policy
4. Attempt to visit the logic app "Advanced Tools" web app, or perform a Kudu-based deployment from private VNet.

Result = 403 forbidden (IP Address)

It appears that Apps (Micrsoft.Web/sites) re-use an ARM/bicep property for different purposes depending on whether their underlying App Service Plan (ASP) or App Service Environment is deployed as a public or private instance. This property is flagged as a Policy violation when you attempt to deploy an App with it enabled.

On a private ASE/ASP the Access Restrictions screen for an App (in this case a Logic App) you will see this when the deployment meets with the public access policy. Note it reads Allow direct access.

In this state you are unable to access the App or its SCM (kudu) API and receive a 403 (IP Address) error. This means you cannot deploy any code using CI/CD or browse to HTTP endpoints that may be served.

If you attempt to enable the feature you receive a policy error and the setting does not change.

The public configuration experience is seen on this Microsoft Learn page on App Services has the text reading Allow public access which suggests the property is used for different purposes depending on deployment.

I have not tested, but I expect attempting to deploy a Web App will also trigger a policy violation.

Ideally Policy should exclude privately configured App Services to avoid blocking deployments/functionality.