Merge pull request #311928 from riturajc/appgwpace/cve-docs-and-key-vault-limitation

[CSS Networking] Document CVE coverage and certificate requirements for Application Gateway

Author: prmerger-automator[bot]

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 | ✓ | ✓ |

articles/application-gateway/ssl-overview.md

@@ -120,11 +120,10 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 
 ### Frontend TLS connection (client to application gateway)
 
-
-|Scenario | v1 | v2 |
+| Scenario | v1 | v2 |
 | --- | --- | --- |
-| If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag | Returns the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. | Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners|
-| If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" | Resets the connection | Returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners
+| If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag | Returns the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. | Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners |
+| If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" | Resets the connection | Returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners |
 | If the client doesn't specify SNI header and if there's a basic listener configured with a certificate | Returns the certificate configured in the basic listener to the client (default or fallback certificate) | Returns the certificate of the HTTPS listener with the highest priority routing rule. The basic listener certificate is **not** used as a fallback. |
 
 > [!IMPORTANT]
@@ -139,26 +138,20 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 >
 > With this configuration, any connection without a matching SNI header receives the self-signed certificate instead of a valid site certificate. This prevents IP-only connections from obtaining information about your hosted sites.
 
-> [!NOTE]
-> For the V1 SKU, when the client doesn't specify an SNI header, it's recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.
-
-> [!TIP]
-> The SNI flag can be configured with PowerShell or by using an ARM template. For more information, see [RequireServerNameIndication](/powershell/module/az.network/set-azapplicationgatewayhttplistener#-requireservernameindication) and [Quickstart: Direct web traffic with Azure Application Gateway - ARM template](quick-create-template.md#review-the-template).
-
 ### Backend TLS connection (application gateway to the backend server)
 
 #### For probe traffic
 
 
-|Scenario | v1 | v2 |
+| Scenario | v1 | v2 |
 | --- | --- | --- |
-| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probe uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation.
-| When an FQDN or SNI is NOT configured (only IP address is available)  | SNI (server_name) won’t be set. <br> **Note:** In this case, the backend server should be able to return a default/fallback certificate and this should be allow-listed in HTTP settings under authentication certificate. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures | If the Custom Probe or Backend Settings use an IP address in the hostname field, the SNI is not set, in accordance with [RFC 6066](https://tools.ietf.org/html/rfc6066). This includes cases where the default probe uses 127.0.0.1. |
+| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probes uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation. |
+| When an FQDN or SNI is NOT configured (only IP address is available) | SNI (server_name) won’t be set. <br> **Note:** In this case, the backend server should be able to return a default/fallback certificate and this should be allow-listed in HTTP settings under authentication certificate. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures | If the Custom Probe or Backend Settings use an IP address in the hostname field, the SNI is not set, in accordance with [RFC 6066](https://tools.ietf.org/html/rfc6066). This includes cases where the default probe uses 127.0.0.1. |
 
 #### For live traffic
 
 
-|Scenario | v1 | v2 |
+| Scenario | v1 | v2 |
 | --- | --- | --- |
 | When an FQDN or SNI is available | The SNI is set using the backend server's FQDN. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – SNI is set according to the following order of precedence: <br> a) Backend Setting’s hostname (as per Overridden value or Pick from backend server) <br> b) Host header of the incoming client request <br><br> 2. **Configurable** <br> Use specific SNI: Uses this fixed hostname for validation. <br> Skip SNI: No Subject Name validation. | 
 | When an FQDN or SNI is NOT available (only IP address is available) | SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066) if the backend pool entry isn't an FQDN | SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066). |