Merge branch 'main' into release-aio-2602

Author: v-alje

articles/app-service/networking-features.md

@@ -72,6 +72,9 @@ The following outbound use cases suggest how to use App Service networking featu
 
 Azure App Service scale units support many customers in each deployment. The Free and Shared SKU plans host customer workloads on multitenant workers. The Basic and higher plans host customer workloads that are dedicated to only one App Service plan. If you have a Standard App Service plan, all the apps in that plan run on the same worker. If you scale out the worker, all the apps in that App Service plan are replicated on a new worker for each instance in your App Service plan.
 
+> [!NOTE]
+> Port 445 (SMB) is blocked by default in the Azure App Service sandbox and cannot be used to access on-premises or public resources.
+
 #### Outbound addresses
 
 The worker virtual machines are broken down in large part by the App Service plans. The Free, Shared, Basic, Standard, and Premium plans all use the same worker virtual machine type. The PremiumV2 plan uses another virtual machine type. PremiumV3 uses yet another virtual machine type. And PremiumV4 uses yet another virtual machine type.

articles/application-gateway/configuration-infrastructure.md

@@ -82,12 +82,12 @@ You can use the built-in roles, such as [Network contributor](../role-based-acce
 ## Permissions
 Depending on whether you're creating new resources or using existing ones, add the appropriate permissions from the following list:
 
-|Resource | Resource status | Required Azure permissions |
-|---|---|---|
-| Subnet | Create new| `Microsoft.Network/virtualNetworks/subnets/write' <br> 'Microsoft.Network/virtualNetworks/subnets/join/action` |
-| Subnet | Use existing| `Microsoft.Network/virtualNetworks/subnets/read` <br> `Microsoft.Network/virtualNetworks/subnets/join/action` |
-| IP addresses| Create new| `Microsoft.Network/publicIPAddresses/write` <br> `Microsoft.Network/publicIPAddresses/join/action` |
-| IP addresses  | Use existing| `Microsoft.Network/publicIPAddresses/read` <br> `Microsoft.Network/publicIPAddresses/join/action` |
+| Resource | Resource status | Required Azure permissions |
+| --- | --- | --- |
+| Subnet | Create new | `Microsoft.Network/virtualNetworks/subnets/write' <br> 'Microsoft.Network/virtualNetworks/subnets/join/action` |
+| Subnet | Use existing | `Microsoft.Network/virtualNetworks/subnets/read` <br> `Microsoft.Network/virtualNetworks/subnets/join/action` |
+| IP addresses | Create new | `Microsoft.Network/publicIPAddresses/write` <br> `Microsoft.Network/publicIPAddresses/join/action` |
+| IP addresses | Use existing | `Microsoft.Network/publicIPAddresses/read` <br> `Microsoft.Network/publicIPAddresses/join/action` |
 | ApplicationGatewayWebApplicationFirewallPolicies | Create new / Update existing | `Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/write` <br> `Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/read` <br> `Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/join/action` |
 
 For more information, see [Azure permissions for Networking](../role-based-access-control/permissions/networking.md) and [Virtual network permissions](../virtual-network/virtual-network-manage-subnet.md#permissions).
@@ -148,43 +148,43 @@ To use an NSG with your application gateway, you need to create or retain some e
 
 **Client traffic**: Allow incoming traffic from the expected clients (as source IP or IP range), and for the destination as your application gateway's entire subnet IP prefix and inbound access ports. For example, if you have listeners configured for ports 80 and 443, you must allow these ports. You can also set this rule to `Any`.
 
-| Source  | Source ports | Destination | Destination ports | Protocol | Access |
-|---|---|---|---|---|---|
-|`<as per need>`|Any|`<Subnet IP Prefix>`|`<listener ports>`|TCP|Allow|
+| Source | Source ports | Destination | Destination ports | Protocol | Access |
+| --- | --- | --- | --- | --- | --- |
+| `<as per need>` | Any | `<Subnet IP Prefix>` | `<listener ports>` | TCP | Allow |
 
 After you configure *active public and private listeners* (with rules) *with the same port number*, your application gateway changes the **Destination** of all inbound flows to the frontend IPs of your gateway. This change occurs even for listeners that aren't sharing any port. You must include your gateway's frontend public and private IP addresses in the **Destination** of the inbound rule when you use the same port configuration.
 
-| Source  | Source ports | Destination | Destination ports | Protocol | Access |
-|---|---|---|---|---|---|
-|`<as per need>`|Any|`<Public and Private frontend IPs>`|`<listener ports>`|TCP|Allow|
+| Source | Source ports | Destination | Destination ports | Protocol | Access |
+| --- | --- | --- | --- | --- | --- |
+| `<as per need>` | Any | `<Public and Private frontend IPs>` | `<listener ports>` | TCP | Allow |
 
 **Infrastructure ports**: Allow incoming requests from the source as the **GatewayManager** service tag and **Any** destination. The destination port range differs based on SKU and is required for communicating the status of the backend health. These ports are protected/locked down by Azure certificates. External entities can't initiate changes on those endpoints without appropriate certificates in place.
 
 - **V2**: Ports 65200-65535
 - **V1**: Ports 65503-65534
 
-| Source  | Source ports | Destination | Destination ports | Protocol | Access |
-|---|---|---|---|---|---|
-|GatewayManager|Any|Any|`<as per SKU given above>`|TCP|Allow|
+| Source | Source ports | Destination | Destination ports | Protocol | Access |
+| --- | --- | --- | --- | --- | --- |
+| GatewayManager | Any | Any | `<as per SKU given above>` | TCP | Allow |
 
 > [!TIP]
 > The communication with Gateway Manager service is regional by default.
 
 **Azure Load Balancer probes**: Allow incoming traffic from the source as the **AzureLoadBalancer** service tag. This rule is created by default for [NSGs](../virtual-network/network-security-groups-overview.md). You must not override it with a manual **Deny** rule to ensure smooth operations of your application gateway.
 
-| Source  | Source ports | Destination | Destination ports | Protocol | Access |
-|---|---|---|---|---|---|
-|AzureLoadBalancer|Any|Any|Any|Any|Allow|
+| Source | Source ports | Destination | Destination ports | Protocol | Access |
+| --- | --- | --- | --- | --- | --- |
+| AzureLoadBalancer | Any | Any | Any | Any | Allow |
 
 You can block all other incoming traffic by using a **Deny All** rule.
 
 #### Outbound rules
 
 **Outbound to the internet**: Allow outbound traffic to the internet for all destinations. This rule is created by default for [NSGs](../virtual-network/network-security-groups-overview.md). You must not override it with a manual **Deny** rule to ensure smooth operations of your application gateway. Outbound NSG rules that deny any outbound connectivity must not be created.
 
-| Source  | Source ports | Destination | Destination ports | Protocol | Access |
-|---|---|---|---|---|---|
-|Any|Any|Internet|Any|Any|Allow|
+| Source | Source ports | Destination | Destination ports | Protocol | Access |
+| --- | --- | --- | --- | --- | --- |
+| Any | Any | Internet | Any | Any | Allow |
 
 > [!NOTE]
 > Application Gateways that don't have [Network Isolation](application-gateway-private-deployment.md#route-table-control) enabled don't allow traffic to be sent between peered VNets when **Allow traffic to remote virtual network** is disabled.

articles/application-gateway/for-containers/container-networking.md

@@ -28,7 +28,7 @@ Azure Kubernetes Service (AKS) uses two main networking models: **overlay** netw
 When choosing a networking model, consider the use cases for each CNI plugin and the type of network model it uses:
 
 | CNI plugin | Networking model | Use case highlights |
-|-------------|----------------------|-----------------------|
+| ------------- | ---------------------- | ----------------------- |
 | **Azure CNI Overlay** | Overlay | - Best for VNET IP conservation<br/>- Max node count supported by API Server + 250 pods per node<br/>- Simpler configuration<br/> - No direct external pod IP access |
 | **Azure CNI Pod Subnet** | Flat | - Direct external pod access<br/>- Modes for efficient VNet IP usage _or_ large cluster scale support |
 | **Azure CNI Node Subnet** | Flat | - Direct external pod access<br/>- Simpler configuration <br/>- Limited scale <br/>- Inefficient use of VNet IPs |
@@ -72,10 +72,16 @@ A: Yes, upgrade of the AKS cluster from CNI to CNI Overlay and Application Gatew
 > [!WARNING]
 > Ensure the Application Gateway for Containers subnet is a /24 before upgrading. Upgrading from CNI to CNI Overlay with a larger subnet (/23 or larger) will lead to an outage and require the Application Gateway for Containers subnet to be recreated with a /24 subnet size.
 
-Q: Can I upgrade an existing cluster with Kubenet to CNI Overlay?
-
+Q: Can I upgrade an existing cluster with Kubenet to CNI Overlay?  
 A: Yes, however, installation of Application Gateway for Containers on a cluster with Kubenet isn't supported. Install Application Gateway for Containers post-upgrade to CNI Overlay.
 
+Q: If I use Application Gateway for Containers with CNI Overlay, can I forward requests to Azure Firewall or a Network Virtual Appliance (NVA)?  
+A: No. With CNI Overlay, NVAs don't have access to proxy traffic to the overlay network.  
+If you need Azure services or NVAs to access the overlay network, use Azure CNI (flat networking) instead of CNI Overlay.
+
+Q: Can I deploy Application Gateway for Containers in a separate virtual network from my AKS cluster?  
+A: No. Separate virtual networks for Application Gateway for Containers and AKS aren't currently supported. Application Gateway for Containers must be deployed in the same virtual network as your AKS cluster.
+
 ## Next steps
 
 * [Deploy ALB Controller - Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md)

articles/application-gateway/for-containers/how-to-ssl-offloading-gateway-api.md

@@ -25,6 +25,9 @@ Application Gateway for Containers enables SSL [offloading](/azure/architecture/
 
 ## Prerequisites
 
+> [!NOTE]
+> Certificates for Application Gateway for Containers must be stored as Kubernetes secrets. Azure Key Vault integration via the [Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported because Application Gateway for Containers requires certificates to be local to the cluster and cannot mount them from external volumes. For automated certificate management, consider using [cert-manager with Let's Encrypt](how-to-cert-manager-lets-encrypt-gateway-api.md).
+
 1. If following the BYO deployment strategy, ensure that you set up your Application Gateway for Containers resources and ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md))
 2. If following the ALB managed deployment strategy, ensure that you provision your ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md)) and the Application Gateway for Containers resources via the  [ApplicationLoadBalancer custom resource](quickstart-create-application-gateway-for-containers-managed-by-alb-controller.md).
 3. Deploy sample HTTPS application

articles/application-gateway/for-containers/how-to-ssl-offloading-ingress-api.md

@@ -22,6 +22,9 @@ Application Gateway for Containers enables SSL [offloading](/azure/architecture/
 
 ## Prerequisites
 
+> [!NOTE]
+> Certificates for Application Gateway for Containers must be stored as Kubernetes secrets. Azure Key Vault integration via the [Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported because Application Gateway for Containers requires certificates to be local to the cluster and cannot mount them from external volumes. For automated certificate management, consider using [cert-manager with Let's Encrypt](how-to-cert-manager-lets-encrypt-ingress-api.md).
+
 1. If you follow the BYO deployment strategy, ensure that you set up your Application Gateway for Containers resources and ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md))
 2. If you follow the ALB managed deployment strategy, ensure that you provision your ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md)) and the Application Gateway for Containers resources via the [ApplicationLoadBalancer custom resource](quickstart-create-application-gateway-for-containers-managed-by-alb-controller.md).
 3. Deploy a sample HTTPS application:

articles/application-gateway/for-containers/migrate-from-agic-to-agc.md

@@ -65,7 +65,7 @@ Here's a summarized list of AGIC annotations and whether Application Gateway for
 | [Private frontend](migrate-from-agic-to-agc.md#private-frontend) | appgw.ingress.kubernetes.io/use-private-ip | Not supported | Not supported |
 | [Web Application Firewall (WAF)](migrate-from-agic-to-agc.md#waf) | appgw.ingress.kubernetes.io/waf-policy-for-path | [Web Application Firewall (WAF)](web-application-firewall.md) | Not supported |
 | [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-hostname | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
-| [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-port |  [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
+| [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-port | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
 | [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-path | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
 | [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-status-codes | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
 | [Custom health probe](migrate-from-agic-to-agc.md#custom-health-probes) | appgw.ingress.kubernetes.io/health-probe-interval | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) | [HealthCheckPolicy](migrate-from-agic-to-agc.md#healthcheckpolicy) |
@@ -227,6 +227,11 @@ Direct certificate upload and reference to a certificate in Azure Key Vault isn'
 
 Secrets should be stored in [AKS Secret Store](/azure/aks/concepts-security#kubernetes-secrets) and referenced by name.
 
+> [!IMPORTANT]
+> Application Gateway for Containers requires certificates to be local to the AKS cluster and cannot mount them from external volumes. As a result, using [Azure Key Vault with the Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported for Application Gateway for Containers certificates.
+>
+> To use certificates from Azure Key Vault, you must first sync them to Kubernetes secrets. Consider using [cert-manager](how-to-cert-manager-lets-encrypt-gateway-api.md) with Let's Encrypt for automated certificate management, or manually import certificates from Key Vault into Kubernetes secrets.
+
 ### Establishing backend certificate chain trust
 
 AGIC annotation
@@ -249,7 +254,7 @@ Application Gateway for Containers allows customers to reference prebuild TLS po
 
 #### Frontend TLS Policy in Gateway API
 
-To use this feature, you must use Gateway API. More details on TLS Policy are found [here](tls-policy.md).
+To use this feature, you must use Gateway API. More details on TLS Policy are found in the [TLS Policy documentation](tls-policy.md).
 
 >[!Note]
 >The Predefined policy names and cipher suites are different from Application Gateway Ingress Controller. Please refer to the [predefined TLS policy table](tls-policy.md#predefined-tls-policy).
@@ -361,7 +366,7 @@ AGIC annotation
 
 Application Gateway for Containers implementation
 
-Request timeouts are nonconfigurable in Application Gateway for Containers. A list of default timeout values are documented [here](application-gateway-for-containers-components.md#request-timeouts).
+Request timeouts are nonconfigurable in Application Gateway for Containers. A list of default timeout values are documented in [default timeout values](application-gateway-for-containers-components.md#request-timeouts).
 
 ### Frontend port override
 

articles/application-gateway/for-containers/tls-policy.md

@@ -28,8 +28,8 @@ Application Gateway for Containers offers two predefined security policies. You
 
 The following table shows the list of cipher suites and minimum protocol version support for each predefined policy. The ordering of the cipher suites determines the priority order during TLS negotiation. To know the exact ordering of the cipher suites for these predefined policies.
 
-| Predefined policy names | 2023-06  | 2023-06-S |
-| ---------- | ---------- | ---------- |
+| Predefined policy names | 2023-06 | 2023-06-S |
+| --- | --- | --- |
 | **Minimum protocol version** | TLS 1.2 | TLS 1.2 |
 | **Enabled protocol versions** | TLS 1.2, TLS 1.3 | TLS 1.2, TLS 1.3 |
 | TLS_AES_256_GCM_SHA384 | ✓ | ✓ |