Merge pull request #286515 from MicrosoftDocs/main

9/11 11:00 AM IST Publish

Author: PhilKang0704

articles/application-gateway/parameter-based-path-selection-portal.md

@@ -0,0 +1,59 @@
+---
+title: Route traffic using parameter based path selection in portal - Azure Application Gateway
+description: Learn how to use the Azure portal to configure an Azure Application Gateway to choose the backend pool based on the value of a header, part of URL, or query string in the request.
+services: application-gateway
+author: greg-lindsay
+ms.service: azure-application-gateway
+ms.topic: how-to
+ms.date: 09/10/2024
+ms.author: greglin
+ms.custom: mvc
+---
+# Perform parameter based path selection with Azure Application Gateway - Azure portal
+
+This article describes how to use the Azure portal to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to perform parameter based path selection by combining the capabilities of URL Rewrite with path-based routing.
+
+If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
+
+## Before you begin
+
+You need to have an Application Gateway v2 SKU instance to complete the steps in this article. URL rewrite and rewriting headers aren't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
+
+
+## Sign in to Azure
+
+Sign in to the [Azure portal](https://portal.azure.com/) with your Azure account.
+
+## Configure parameter based path selection
+
+For this example, you have a shopping website and the product category is passed as query string in the URL, and you want to route the request to backend based on the query string, then:
+
+**Step 1:**  Create a path-map as shown in the following image:
+
+:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-1.png" alt-text="A screenshot of URL rewrite scenario 1-1.":::
+
+**Step 2 (a):** Create a rewrite set which has 3 rewrite rules: 
+
+* The first rule has a condition that checks the *query_string* variable for *category=shoes* and has an action that rewrites the URL path to /*listing1* and has **Reevaluate path map** enabled
+
+* The second rule has a condition that checks the *query_string* variable for *category=bags* and has an action that rewrites the URL path to /*listing2*  and has **Reevaluate path map** enabled
+
+* The third rule has a condition that checks the *query_string* variable for *category=accessories* and has an action that rewrites the URL path to /*listing3* and has **Reevaluate path map** enabled
+
+    :::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-2.png" alt-text="A screenshot of URL rewrite scenario 1-2.":::
+
+ 
+**Step 2 (b):** Associate this rewrite set with the default path of the previous path-based rule:
+
+:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-3.png" alt-text="A screenshot of URL rewrite scenario 1-3.":::
+
+If the user requests *contoso.com/listing?category=any*, then it's matched with the default path since none of the path patterns in the path map (/listing1, /listing2, /listing3) are matched. Since you associated the previous rewrite set with this path, this rewrite set is evaluated. Because the query string doesn't match the condition in any of the 3 rewrite rules in this rewrite set, no rewrite action takes place. Therefore, the request is routed unchanged to the backend associated with the default path (which is *GenericList*).
+
+If the user requests *contoso.com/listing?category=shoes*, then the default path is matched. However, in this case, the condition in the first rule matches. Therefore, the action associated with the condition is executed, which rewrites the URL path to /*listing1*  and reevaluates the path-map. When the path-map is reevaluated, the request matches the path associated with pattern */listing1* and the request is routed to the backend associated with this pattern (ShoesListBackendPool).
+
+> [!NOTE]
+> This scenario can be extended to any header or cookie value, URL path, query string or server variables based on the conditions defined and essentially enables you to route requests based on those conditions.
+
+## Next steps
+
+To learn more about how to set up some common use cases, see [common header rewrite scenarios](./rewrite-http-headers-url.md).

articles/application-gateway/rewrite-http-headers-url.md

@@ -4,7 +4,7 @@ description: This article provides an overview of rewriting HTTP headers and URL
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: conceptual
-ms.date: 09/06/2024
+ms.date: 09/10/2024
 ms.author: greglin
 ---
 
@@ -203,7 +203,7 @@ Here are the steps for replacing the hostname:
 1. Create a rewrite rule with a condition that evaluates if the location header in the response contains azurewebsites.net. Enter the pattern `(https?):\/\/.*azurewebsites\.net(.*)$`.
 2. Perform an action to rewrite the location header so that it has the application gateway's hostname. Do this by entering `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. Alternatively, you can also use the server variable `host` to set the hostname to match the original request.
 
-![A screenshow of the modify location header action.](./media/rewrite-http-headers-url/app-service-redirection.png)
+   ![A screenshot of the modify location header action.](./media/rewrite-http-headers-url/app-service-redirection.png)
 
 #### Implement security HTTP headers to prevent vulnerabilities
 
@@ -229,34 +229,14 @@ You can evaluate an HTTP request or response header for the presence of a header
 
 #### Parameter based path selection
 
-To accomplish scenarios where you want to choose the backend pool based on the value of a header, part of the URL, or query string in the request, you can use the combination of URL Rewrite capability and path-based routing. For example, if you have a shopping website and the product category is passed as query string in the URL, and you want to route the request to backend based on the query string, then:
+To accomplish scenarios where you want to choose the backend pool based on the value of a header, part of the URL, or query string in the request, you can use a combination of URL Rewrite capability and path-based routing. 
 
-**Step1:**  Create a path-map as shown in the image below
+To do this, create a rewrite set with a condition that checks for a specific parameter (query string, header, etc.) and then performs an action where it changes the URL path (ensure **Reevaluate path map** is enabled). The rewrite set must then be associated to a path based rule. The path based rule must contain the same URL paths specified in the rewrite set and their corresponding backend pool. 
 
-:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-1.png" alt-text="URL rewrite scenario 1-1.":::
+Thus, the rewrite set allows users to check for a specific parameter and assign it a new path, and the path based rule allows users to assign backend pools to those paths. As long as "Reevaluate path map" is enabled, traffic routs based on the path specified in the rewrite set. 
 
-**Step 2 (a):** Create a rewrite set which has 3 rewrite rules: 
+For a use case example using query strings, see [Route traffic using parameter based path selection in portal](parameter-based-path-selection-portal.md).
 
-* The first rule has a condition that checks the *query_string* variable for *category=shoes* and has an action that rewrites the URL path to /*listing1* and has **Reevaluate path map** enabled
-
-* The second rule has a condition that checks the *query_string* variable for *category=bags* and has an action that rewrites the URL path to /*listing2*  and has **Reevaluate path map** enabled
-
-* The third rule has a condition that checks the *query_string* variable for *category=accessories* and has an action that rewrites the URL path to /*listing3* and has **Reevaluate path map** enabled
-
-:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-2.png" alt-text="URL rewrite scenario 1-2.":::
-
- 
-
-**Step 2 (b):** Associate this rewrite set with the default path of the above path-based rule
-
-:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-3.png" alt-text="URL rewrite scenario 1-3.":::
-
-If the user requests *contoso.com/listing?category=any*, then it's matched with the default path since none of the path patterns in the path map (/listing1, /listing2, /listing3) are matched. Since you associated the previous rewrite set with this path, this rewrite set is evaluated. Because the query string won't match the condition in any of the 3 rewrite rules in this rewrite set, no rewrite action takes place. Therefore, the request is routed unchanged to the backend associated with the default path (which is *GenericList*).
-
-If the user requests *contoso.com/listing?category=shoes*, then the default path is matched. However, in this case the condition in the first rule matches. Therefore, the action associated with the condition is executed, which rewrites the URL path to /*listing1*  and reevaluates the path-map. When the path-map is reevaluated, the request matches the path associated with pattern */listing1* and the request is routed to the backend associated with this pattern (ShoesListBackendPool).
-
-> [!NOTE]
-> This scenario can be extended to any header or cookie value, URL path, query string or server variables based on the conditions defined and essentially enables you to route requests based on those conditions.
 
 #### Rewrite query string parameters based on the URL
 

articles/application-gateway/toc.yml

@@ -271,6 +271,10 @@
       items:
         - name: Azure portal
           href: rewrite-url-portal.md
+    - name: Parameter based path selection
+      items:
+        - name: Azure portal
+          href: parameter-based-path-selection-portal.md
   - name: Configure custom probes
     items:
       - name: Portal

articles/azure-app-configuration/quickstart-azure-kubernetes-service.md

@@ -241,7 +241,7 @@ Add following key-values to the App Configuration store and leave **Label** and
          --namespace azappconfig-system \
          --create-namespace
     ```
-
+    
     > [!TIP]
     > The App Configuration Kubernetes Provider is also available as an AKS extension. This integration allows for seamless installation and management via the Azure CLI, ARM templates, or Bicep templates. Utilizing the AKS extension facilitates automatic minor/patch version updates, ensuring your system is always up-to-date. For detailed installation instructions, please refer to the [Azure App Configuration extension for Azure Kubernetes Service](/azure/aks/azure-app-configuration).
 
@@ -261,10 +261,10 @@ Add following key-values to the App Configuration store and leave **Label** and
           key: mysettings.json
       auth:
         workloadIdentity:
-          managedIdentityClientId: <your-managed-identity-client-id>
+          serviceAccountName: <your-service-account-name>
     ```
 
-    Replace the value of the `endpoint` field with the endpoint of your Azure App Configuration store. Follow the steps in [use workload identity](./reference-kubernetes-provider.md#use-workload-identity) and update the `auth` section with the client ID of the user-assigned managed identity you created.
+    Replace the value of the `endpoint` field with the endpoint of your Azure App Configuration store. Proceed to the next step to update the `auth` section with your authentication information.
     
     > [!NOTE]
     > `AzureAppConfigurationProvider` is a declarative API object. It defines the desired state of the ConfigMap created from the data in your App Configuration store with the following behavior:
@@ -273,6 +273,8 @@ Add following key-values to the App Configuration store and leave **Label** and
     > - The ConfigMap will be reset based on the present data in your App Configuration store if it's deleted or modified by any other means.
     > - The ConfigMap will be deleted if the App Configuration Kubernetes Provider is uninstalled.
 
+1. Follow the [instructions to use the workload identity](./reference-kubernetes-provider.md#use-workload-identity) to authenticate with your App Configuration store. Update the *appConfigurationProvider.yaml* file by replacing the `serviceAccountName` field with the name of the service account you created. For more information on other authentication methods, refer to the examples in the [Authentication](./reference-kubernetes-provider.md#authentication) section.
+
 1. Update the *deployment.yaml* file in the *Deployment* directory to use the ConfigMap `configmap-created-by-appconfig-provider` as a mounted data volume. It is important to ensure that the `volumeMounts.mountPath` matches the `WORKDIR` specified in your *Dockerfile* and the *config* directory created before.
    
     ```yaml
@@ -370,6 +372,10 @@ Ensure that you specify the correct key-value selectors to match the expected da
 
 You can customize the installation by providing additional Helm values when installing the Azure App Configuration Kubernetes Provider. For example, you can set the log level, configure the provider to run on a specific node, or disable the workload identity. Refer to the [installation guide](./reference-kubernetes-provider.md#installation) for more information.
 
+#### Why am I unable to authenticate with Azure App Configuration using workload identity after upgrading the provider to version 2.0.0?
+
+Starting with version 2.0.0, a user-provided service account is required for authenticating with Azure App Configuration [using workload identity](./reference-kubernetes-provider.md#use-workload-identity). This change enhances security through namespace isolation. Previously, a Kubernetes provider’s service account was used for all namespaces. For updated instructions, see the documentation on using workload identity. If you need time to migrate when upgrading to version 2.0.0, you can temporarily set `workloadIdentity.globalServiceAccountEnabled=true` during provider installation. Please note that support for using the provider’s service account will be deprecated in a future release.
+
 ## Clean up resources
 
 Uninstall the App Configuration Kubernetes Provider from your AKS cluster if you want to keep the AKS cluster.