You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{
"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.
resourcefunctionApp_resource'Microsoft.Web/sites@2022-03-01' = {
name: appNamelocation: locationkind: kindidentity: {
type: 'SystemAssigned'
}
tags: tagsproperties: {
serverFarmId: appServiceResourceId// required for direct access from a Virtual NetworkpublicNetworkAccess: 'Enabled'siteConfig: {
appSettings: appSettingsnetFrameworkVersion: workerVersion// required for direct access from a Virtual NetworkpublicNetworkAccess: 'Enabled'vnetRouteAllEnabled: vnetIntegratedalwaysOn: trueipSecurityRestrictions: [
{
ipAddress: 'Any'action: 'Allow'priority: 2147483647name: 'Allow all'description: 'Allow all access'
}
]
scmIpSecurityRestrictionsUseMain: true
}
httpsOnly: true
}
}
Reproduction scenario:
Enable Policy for Subscription
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,
Deploy Logic App with properties to meet Policy
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.
The text was updated successfully, but these errors were encountered:
sjwaight
changed the title
App Service apps should disable public network access breaks Apps deployed to private App Service Plans without Private Endpoints
"App Service apps should disable public network access" breaks apps deployed to private App Service Plans without Private Endpoints
Jul 12, 2023
Policy failure snippet:
Note this seems to break Function Apps via a different policy.
The
ipSecurityRestrictions
are what cannot be enabled with the above policy and thepublicNetworkAccess
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.Reproduction scenario:
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.
The text was updated successfully, but these errors were encountered: