Images and content refresh

Author: madsd

articles/app-service/app-service-ip-restrictions.md

@@ -5,7 +5,7 @@ author: madsd
 
 ms.assetid: 3be1f4bd-8a81-4565-8a56-528c037b24bd
 ms.topic: article
-ms.date: 03/21/2022
+ms.date: 09/01/2022
 ms.author: madsd
 
 ---
@@ -75,9 +75,8 @@ On the **Add Access Restriction** pane, when you create a rule, do the following
 
 1. Optionally, enter a name and description of the rule.
 1. In the **Priority** box, enter a priority value.
-1. In the **Type** drop-down list, select the type of rule.
-
-The different types of rules are described in the following sections.
+1. In the **Type** drop-down list, select the type of rule. The different types of rules are described in the following sections.
+1. After typing in the rule specific input select **Save** to save the changes.
 
 > [!NOTE]
 > - There is a limit of 512 access restriction rules. If you require more than 512 access restriction rules, we suggest that you consider installing a standalone security product, such as Azure Front Door, Azure App Gateway, or an alternative WAF.
@@ -120,7 +119,9 @@ All available service tags are supported in access restriction rules. Each servi
 
 1. To begin editing an existing access restriction rule, on the **Access Restrictions** page, select the rule you want to edit.
 
-1. On the **Edit Access Restriction** pane, make your changes, and then select **Update rule**. Edits are effective immediately, including changes in priority ordering.
+1. On the **Edit Access Restriction** pane, make your changes, and then select **Update rule**. 
+
+1. Select **Save** to save the changes.
 
    :::image type="content" source="media/app-service-ip-restrictions/access-restrictions-ip-edit.png?v2" alt-text="Screenshot of the 'Edit Access Restriction' pane in the Azure portal, showing the fields for an existing access restriction rule.":::
 
@@ -129,7 +130,9 @@ All available service tags are supported in access restriction rules. Each servi
 
 ### Delete a rule
 
-To delete a rule, on the **Access Restrictions** page, select the ellipsis (**...**) next to the rule you want to delete, and then select **Remove**.
+1. To delete a rule, on the **Access Restrictions** page, check the rule or rules you want to delete, and then select **Delete**. 
+
+1. Select **Save** to save the changes.
 
 :::image type="content" source="media/app-service-ip-restrictions/access-restrictions-delete.png" alt-text="Screenshot of the 'Access Restrictions' page, showing the 'Remove' ellipsis next to the access restriction rule to be deleted.":::
 
@@ -170,7 +173,7 @@ For a scenario where you want to explicitly block a single IP address or a block
 
 ### Restrict access to an SCM site 
 
-In addition to being able to control access to your app, you can restrict access to the SCM site that's used by your app. The SCM site is both the web deploy endpoint and the Kudu console. You can assign access restrictions to the SCM site from the app separately or use the same set of restrictions for both the app and the SCM site. When you select the **Same restrictions as \<app name>** check box, everything is blanked out. If you clear the check box, your SCM site settings are reapplied. 
+In addition to being able to control access to your app, you can restrict access to the SCM (Advanced tool) site that's used by your app. The SCM site is both the web deploy endpoint and the Kudu console. You can assign access restrictions to the SCM site from the app separately or use the same set of restrictions for both the app and the SCM site. When you select the **Use main site rules** check box, the rules list will be hidden and it will use the rules from the main site. If you clear the check box, your SCM site settings will appear again. 
 
 :::image type="content" source="media/app-service-ip-restrictions/access-restrictions-scm-browse.png" alt-text="Screenshot of the 'Access Restrictions' page in the Azure portal, showing that no access restrictions are set for the SCM site or the app.":::
 

articles/app-service/media/app-service-ip-restrictions/access-restrictions-browse.png

@@ -5,7 +5,7 @@ author: madsd
 
 ms.assetid: 5c61eed1-1ad1-4191-9f71-906d610ee5b7
 ms.topic: article
-ms.date: 09/20/2021
+ms.date: 09/01/2022
 ms.author: madsd
 
 ---
@@ -73,11 +73,11 @@ Azure App Service scale units support many customers in each deployment. The Fre
 
 The worker VMs are broken down in large part by the App Service plans. The Free, Shared, Basic, Standard, and Premium plans all use the same worker VM type. The PremiumV2 plan uses another VM type. PremiumV3 uses yet another VM type. When you change the VM family, you get a different set of outbound addresses. If you scale from Standard to PremiumV2, your outbound addresses will change. If you scale from PremiumV2 to PremiumV3, your outbound addresses will change. In some older scale units, both the inbound and outbound addresses will change when you scale from Standard to PremiumV2. 
 
-There are a number of addresses that are used for outbound calls. The outbound addresses used by your app for making outbound calls are listed in the properties for your app. These addresses are shared by all the apps running on the same worker VM family in the App Service deployment. If you want to see all the addresses that your app might use in a scale unit, there's property called `possibleOutboundAddresses` that will list them. 
+There are many addresses that are used for outbound calls. The outbound addresses used by your app for making outbound calls are listed in the properties for your app. These addresses are shared by all the apps running on the same worker VM family in the App Service deployment. If you want to see all the addresses that your app might use in a scale unit, there's property called `possibleOutboundAddresses` that will list them. 
 
 ![Screenshot that shows app properties.](media/networking-features/app-properties.png)
 
-App Service has a number of endpoints that are used to manage the service.  Those addresses are published in a separate document and are also in the `AppServiceManagement` IP service tag. The `AppServiceManagement` tag is used only in App Service Environments where you need to allow such traffic. The App Service inbound addresses are tracked in the `AppService` IP service tag. There's no IP service tag that contains the outbound addresses used by App Service. 
+App Service has many endpoints that are used to manage the service.  Those addresses are published in a separate document and are also in the `AppServiceManagement` IP service tag. The `AppServiceManagement` tag is used only in App Service Environments where you need to allow such traffic. The App Service inbound addresses are tracked in the `AppService` IP service tag. There's no IP service tag that contains the outbound addresses used by App Service. 
 
 ![Diagram that shows App Service inbound and outbound traffic.](media/networking-features/default-behavior.png)
 
@@ -96,60 +96,15 @@ To learn how to set an address on your app, see [Add a TLS/SSL certificate in Az
 
 ### Access restrictions 
 
-Access restrictions let you filter *inbound* requests. The filtering action takes place on the front-end roles that are upstream from the worker roles where your apps are running. Because the front-end roles are upstream from the workers, you can think of access restrictions as network-level protection for your apps. 
+Access restrictions let you filter *inbound* requests. The filtering action takes place on the front-end roles that are upstream from the worker roles where your apps are running. Because the front-end roles are upstream from the workers, you can think of access restrictions as network-level protection for your apps. For more information about access restrictions, see [Access restrictions overview](./overview-access-restrictions.md).
+
+This feature allows you to build a list of allow and deny rules that are evaluated in priority order. It's similar to the network security group (NSG) feature in Azure networking. You can use this feature in an ASE or in the multi-tenant service. When you use it with an ILB ASE, you can restrict access from private address blocks. To learn how to enable this feature, see [Configuring access restrictions](./app-service-ip-restrictions.md).
 
-This feature allows you to build a list of allow and deny rules that are evaluated in priority order. It's similar to the network security group (NSG) feature in Azure networking. You can use this feature in an ASE or in the multi-tenant service. When you use it with an ILB ASE, you can restrict access from private address blocks.
 > [!NOTE]
 > Up to 512 access restriction rules can be configured per app. 
 
 ![Diagram that illustrates access restrictions.](media/networking-features/access-restrictions.png)
 
-#### IP-based access restriction rules
-
-The IP-based access restrictions feature helps when you want to restrict the IP addresses that can be used to reach your app. Both IPv4 and IPv6 are supported. Some use cases for this feature:
-* Restrict access to your app from a set of well-defined addresses. 
-* Restrict access to traffic coming through an external load-balancing service or other network appliances with known egress IP addresses. 
-
-To learn how to enable this feature, see [Configuring access restrictions][iprestrictions].
-
-> [!NOTE]
-> IP-based access restriction rules only handle virtual network address ranges when your app is in an App Service Environment. If your app is in the multi-tenant service, you need to use [service endpoints](../virtual-network/virtual-network-service-endpoints-overview.md) to restrict traffic to select subnets in your virtual network.
-
-#### Access restriction rules based on service endpoints 
-
-Service endpoints allow you to lock down *inbound* access to your app so that the source address must come from a set of subnets that you select. This feature works together with IP access restrictions. Service endpoints aren't compatible with remote debugging. If you want to use remote debugging with your app, your client can't be in a subnet that has service endpoints enabled. The process for setting service endpoints is similar to the process for setting IP access restrictions. You can build an allow/deny list of access rules that includes public addresses and subnets in your virtual networks.
-
-> [!NOTE]
-> Access restriction rules based on service endpoints are not supported on apps that use IP-based SSL ([App-assigned address](#app-assigned-address)).
-
-Some use cases for this feature:
-
-* Set up an application gateway with your app to lock down inbound traffic to your app.
-* Restrict access to your app to resources in your virtual network. These resources can include VMs, ASEs, or even other apps that use virtual network integration. 
-
-![Diagram that illustrates the use of service endpoints with Application Gateway.](media/networking-features/service-endpoints-appgw.png)
-
-To learn more about configuring service endpoints with your app, see [Azure App Service access restrictions][serviceendpoints].
-
-#### Access restriction rules based on service tags
-
-[Azure service tags][servicetags] are well defined sets of IP addresses for Azure services. Service tags group the IP ranges used in various Azure services and is often also further scoped to specific regions. This allows you to filter *inbound* traffic from specific Azure services. 
-
-For a full list of tags and more information, visit the service tag link above. 
-To learn how to enable this feature, see [Configuring access restrictions][iprestrictions].
-
-#### Http header filtering for access restriction rules
-
-For each access restriction rule, you can add additional http header filtering. This allows you to further inspect the incoming request and filter based on specific http header values. Each header can have up to eight values per rule. The following list of http headers is currently supported: 
-* X-Forwarded-For
-* X-Forwarded-Host
-* X-Azure-FDID
-* X-FD-HealthProbe
-
-Some use cases for http header filtering are:
-* Restrict access to traffic from proxy servers forwarding the host name
-* Restrict access to a specific Azure Front Door instance with a service tag rule and X-Azure-FDID header restriction
-
 ### Private endpoint
 
 Private endpoint is a network interface that connects you privately and securely to your Web App by Azure private link. Private endpoint uses a private IP address from your virtual network, effectively bringing the web app into your virtual network. This feature is only for *inbound* flows to your web app.
@@ -184,7 +139,7 @@ This feature is commonly used to:
 
 Because this feature enables access to on-premises resources without an inbound firewall hole, it's popular with developers. The other outbound App Service networking features are related to Azure Virtual Network. Hybrid Connections doesn't depend on going through a virtual network. It can be used for a wider variety of networking needs. 
 
-Note that App Service Hybrid Connections is unaware of what you're doing on top of it. So you can use it to access a database, a web service, or an arbitrary TCP socket on a mainframe. The feature essentially tunnels TCP packets. 
+App Service Hybrid Connections is unaware of what you're doing on top of it. So you can use it to access a database, a web service, or an arbitrary TCP socket on a mainframe. The feature essentially tunnels TCP packets. 
 
 Hybrid Connections is popular for development, but it's also used in production applications. It's great for accessing a web service or database, but it's not appropriate for situations that involve creating many connections. 
 
@@ -194,7 +149,7 @@ Gateway-required App Service virtual network integration enables your app to mak
 
 ![Diagram that illustrates gateway-required virtual network integration.](media/networking-features/gw-vnet-integration.png)
 
-This feature solves the problem of accessing resources in other virtual networks. It can even be used to connect through a virtual network to either other virtual networks or on-premises. It doesn't work with ExpressRoute-connected virtual networks, but it does work with site-to-site VPN-connected networks. It's usually inappropriate to use this feature from an app in an App Service Environment (ASE) because the ASE is already in your virtual network. Use cases for this feature:
+This feature solves the problem of accessing resources in other virtual networks. It can even be used to connect through a virtual network to either other virtual networks or on-premises. It doesn't work with ExpressRoute-connected virtual networks, but it does work with site-to-site VPN-connected networks. It's inappropriate to use this feature from an app in an App Service Environment (ASE) because the ASE is already in your virtual network. Use cases for this feature:
 
 * Access resources in cross region virtual networks that aren't peered to a virtual network in the region. 
 
@@ -228,7 +183,7 @@ An App Service Environment (ASE) is a single-tenant deployment of the Azure App
 * Access resources across service endpoints. 
 * Access resources across private endpoints. 
 
-With an ASE, you don't need to use virtual network integration because the ASE is already in your virtual network. If you want to access resources like SQL or Azure Storage over service endpoints, enable service endpoints on the ASE subnet. If you want to access resources in the virtual network or private endpoints in the virtual network, you don't need to do any additional configuration. If you want to access resources across ExpressRoute, you're already in the virtual network and don't need to configure anything on the ASE or the apps in it. 
+With an ASE, you don't need to use virtual network integration because the ASE is already in your virtual network. If you want to access resources like SQL or Azure Storage over service endpoints, enable service endpoints on the ASE subnet. If you want to access resources in the virtual network or private endpoints in the virtual network, you don't need to do any extra configuration. If you want to access resources across ExpressRoute, you're already in the virtual network, and don't need to configure anything on the ASE or the apps in it. 
 
 Because the apps in an ILB ASE can be exposed on a private IP address, you can easily add WAF devices to expose just the apps that you want to the internet and help keep the rest secure. This feature can help make the development of multi-tier applications easier. 
 
@@ -283,7 +238,7 @@ If you're hosting both the front end and API app for a multi-tier application, y
 
 Here are some considerations to help you decide which method to use:
 
-* When you use service endpoints, you only need to secure traffic to your API app to the integration subnet. Service endpoints helps to secure the API app, but you could still have data exfiltration from your front-end app to other apps in the app service.
+* When you use service endpoints, you only need to secure traffic to your API app to the integration subnet. Service endpoints help to secure the API app, but you could still have data exfiltration from your front-end app to other apps in the app service.
 * When you use private endpoints, you have two subnets at play, which adds complexity. Also, the private endpoint is a top-level resource and adds management overhead. The benefit of using private endpoints is that you don't have the possibility of data exfiltration. 
 
 Either method will work with multiple front ends. On a small scale, service endpoints are easier to use because you simply enable service endpoints for the API app on the front-end integration subnet. As you add more front-end apps, you need to adjust every API app to include service endpoints with the integration subnet. When you use private endpoints, there's more complexity, but you don't have to change anything on your API apps after you set a private endpoint. 
@@ -313,7 +268,6 @@ If you scan App Service, you'll find several ports that are exposed for inbound
 
 <!--Links-->
 [appassignedaddress]: ./configure-ssl-certificate.md
-[iprestrictions]: ./app-service-ip-restrictions.md
 [serviceendpoints]: ./app-service-ip-restrictions.md
 [hybridconn]: ./app-service-hybrid-connections.md
 [vnetintegrationp2s]: ./overview-vnet-integration.md