Application Gateway-Integration

Artikel
10/19/2023

Drei Varianten von Azure App Service erfordern jeweils eine etwas andere Konfiguration der Integration mit Azure Application Gateway. Die Variationen umfassen regulären App Service (auch als mandantenfähig bezeichnet), eine App Service-Umgebung für internen Lastenausgleich (Internal Load Balancer, ILB) und eine externe App Service-Umgebung.

Dieser Artikel führt Sie durch die Konfiguration von Application Gateway mit App Service (mandantenfähig), indem Dienstendpunkte zum Schützen des Datenverkehrs verwendet werden. Dieser Artikel erörtert auch Überlegungen zur Verwendung privater Endpunkte und zur Integration mit ILB und der externen App Service-Umgebung. Schließlich beschreibt dieser Artikel, wie Sie Zugriffseinschränkungen auf einer Website des Quellcodeverwaltungsmanagers (Source Control Manager, SCM) festlegen.

Integration in App Service (mehrinstanzenfähig)

App Service (mandantenfähig) verfügt über einen öffentlichen Endpunkt mit Internetzugriff. Mithilfe von Dienstendpunkten können Sie dafür sorgen, dass Datenverkehr nur von einem bestimmten Subnetz innerhalb eines virtuellen Azure-Netzwerks zugelassen und alles andere blockiert wird. Im folgenden Szenario verwenden Sie diese Funktion, um sicherzustellen, dass eine App Service-Instanz Datenverkehr nur von einem bestimmten Anwendungsgateway empfangen kann.

Diagram that shows the internet flowing to an application gateway in an Azure virtual network and then flowing through a firewall icon to instances of apps in App Service.

Diese Konfiguration umfasst zwei Teile, nebst der Erstellung der App Service-Instanz und dem Anwendungsgateway. Der erste Teil besteht darin, Dienstendpunkte im Subnetz des virtuellen Netzwerks zu aktivieren, in dem das Anwendungsgateway bereitgestellt wird. Dienstendpunkte sorgen dafür, dass der gesamte Netzwerkdatenverkehr, der das Subnetz in Richtung App Service verlässt, mit der spezifischen Subnetz-ID gekennzeichnet ist.

Der zweite Teil besteht darin, eine Zugriffseinschränkung für die spezifische Web-App festzulegen, um sicherzustellen, dass nur Datenverkehr zugelassen wird, der mit dieser spezifischen Subnetz-ID gekennzeichnet ist. Sie können die Zugriffseinschränkung je nach Ihren Vorlieben mit verschiedenen Tools konfigurieren.

Einrichten von Diensten mithilfe des Azure-Portals

Mit dem Azure-Portal führen Sie vier Schritte aus, um das Setup von App Service und Application Gateway zu erstellen und zu konfigurieren. Wenn Sie bereits über Ressourcen verfügen, können Sie die ersten Schritte überspringen.

Erstellen Sie eine App Service-Instance mithilfe eines der Schnellstarts in der App Service-Dokumentation. Ein Beispiel ist der .NET Core-Schnellstart.
Erstellen Sie ein Anwendungsgateway mithilfe des Portal-Schnellstarts, überspringen Sie jedoch den Abschnitt zum Hinzufügen von Back-End-Zielen.
Konfigurieren Sie App Service als Back-End in Application Gateway, überspringen Sie jedoch den Abschnitt über das Beschränken des Zugriffs.
Erstellen Sie die Zugriffseinschränkung mithilfe von Dienstendpunkten.

Sie können jetzt über Application Gateway auf App Service zugreifen. Wenn Sie versuchen, direkt auf App Service zuzugreifen, sollte der HTTP-Fehler 403 angezeigt werden, der besagt, dass die Web-App Ihren Zugriff blockiert hat.

Screenshot shows the text of Error 403 - Forbidden.

Einrichten von Diensten mithilfe einer Azure Resource Manager-Vorlage

Die Resource Manager-Bereitstellungsvorlage stellt ein vollständiges Szenario bereit. Das Szenario besteht aus einer App Service-Instanz, die mit Dienstendpunkten und einer Zugriffseinschränkung gesperrt ist, um Datenverkehr nur von Application Gateway zu empfangen. Die Vorlage enthält viele intelligente Standardwerte und eindeutige Postfixe, die den Ressourcennamen hinzugefügt werden, um sie einfach zu halten. Wenn Sie diese überschreiben möchten, müssen Sie das Repository klonen oder die Vorlage herunterladen und bearbeiten.

Um die Vorlage anzuwenden, können Sie die Schaltfläche Bereitstellen in Azure in der Beschreibung der Vorlage verwenden. Alternativ können Sie den entsprechenden PowerShell- oder Azure CLI-Code verwenden.

Einrichten von Diensten mithilfe der Azure CLI

Das Azure CLI-Beispiel erstellt eine App Service-Instanz, die mit Dienstendpunkten und einer Zugriffseinschränkung gesperrt ist, um Datenverkehr nur von Application Gateway zu empfangen. Wenn Sie lediglich Datenverkehr von einem vorhandenen Anwendungsgateway zu einer vorhandenen App Service-Instanz isolieren möchten, verwenden Sie den folgenden Befehl:

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

In der Standardkonfiguration stellt der Befehl das Einrichten der Dienstendpunktkonfiguration im Subnetz und der Zugriffseinschränkung in App Service sicher.

Überlegungen zur Verwendung privater Endpunkte

Als Alternative zu Dienstendpunkten können Sie einen privaten Endpunkt verwenden, um den Datenverkehr zwischen Application Gateway und App Service (mandantenfähig) zu sichern. Sie müssen sicherstellen, dass Application Gateway DNS verwenden kann, um die private IP-Adresse der App Service-Apps aufzulösen. Alternativ können Sie die private IP-Adresse im Back-End-Pool verwenden und den Hostnamen in den HTTP-Einstellungen überschreiben.

Diagram that shows traffic flowing to an application gateway in an Azure virtual network and then flowing through a private endpoint to instances of apps in App Service.

Application Gateway speichert die Ergebnisse der DNS-Suche zwischen. Wenn Sie vollqualifizierte Domänennamen (FQDNs) verwenden und die private IP-Adresse mithilfe von DNS-Lookup abrufen, müssen Sie möglicherweise das Anwendungsgateway neu starten, wenn die DNS-Aktualisierung oder die Verknüpfung zu einer privaten Azure-DNS-Zone erfolgt ist, nachdem Sie den Back-End-Pool konfiguriert haben.

Um das Anwendungsgateway neu zu starten, beenden und starten Sie es mithilfe der Azure CLI:

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

Überlegungen zu einer ILB-App Service-Umgebung

Ein ILB-App Service-Umgebung ist für das Internet nicht sichtbar. Datenverkehr zwischen der Instanz und einem Anwendungsgateway ist bereits im virtuellen Netzwerk isoliert. Informationen zum Konfigurieren eines ILB-App Service-Umgebung und dessen Integration in ein Anwendungsgateway mithilfe des Azure-Portals finden Sie in der Schrittanleitung.

Wenn Sie sicherstellen möchten, dass nur Datenverkehr aus dem Application Gateway-Subnetz die App Service-Umgebung erreicht, können Sie eine Netzwerksicherheitsgruppe (NSG) konfigurieren, die sich auf alle Web-Apps in der App Service-Umgebung auswirkt. Für die NSG können Sie den Subnetz-IP-Adressbereich und optional die Ports (80/443) angeben. Damit die App Service-Umgebung ordnungsgemäß funktioniert, achten Sie darauf, die erforderlichen NSG-Regeln nicht zu überschreiben.

Um Datenverkehr an eine einzelne Web-App zu isolieren, müssen Sie IP-basierte Zugriffseinschränkungen verwenden, da Dienstendpunkte nicht mit einer App Service-Umgebung funktionieren. Bei der IP-Adresse muss es sich um die private IP-Adresse des Anwendungsgateways handeln.

Überlegungen zu einer externen App Service-Umgebung

Eine externe App Service-Umgebung verfügt über einen öffentlichen Lastenausgleich wie mandantenfähiger App Service. Dienstendpunkte funktionieren nicht für eine App Service-Umgebung. Aus diesem Grund müssen Sie IP-basierte Zugriffseinschränkungen verwenden, indem Sie die öffentliche IP-Adresse des Anwendungsgateways verwenden. Um eine externe App Service-Umgebung über das Azure-Portal erstellen, können Sie diesen Schnellstart verwenden.

Überlegungen zu einer Kudu/SCM-Website

Die SCM-Website, auch als Kudu bekannt, ist eine für jede Web-App vorhandene Administratorwebsite. Es ist nicht möglich, einen Reverseproxy für die SCM-Website zu verwenden. Wahrscheinlich wollen Sie auch einzelne IP-Adressen oder ein bestimmtes Subnetz sperren.

Wenn Sie die gleichen Zugriffseinschränkungen verwenden möchten wie für die Hauptwebsite, können Sie die Einstellungen mithilfe des folgenden Befehls erben:

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

Wenn Sie individuelle Zugriffseinschränkungen für die SCM-Website hinzufügen möchten, können Sie das --scm-site-Flag verwenden:

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Überlegungen zur Verwendung der Standarddomäne

Das Konfigurieren von Application Gateway, um den Hostnamen zu überschreiben und die Standarddomäne von App Service (in der Regel azurewebsites.net) zu verwenden, ist die einfachste Möglichkeit, die Integration zu konfigurieren. Es ist nicht erforderlich, eine benutzerdefinierte Domäne und ein Zertifikat in App Service zu konfigurieren.

Dieser Artikel erläutert die allgemeinen Überlegungen beim Überschreiben des ursprünglichen Hostnamens. In App Service gibt es zwei Szenarien, in denen Sie bei dieser Konfiguration Vorsicht walten lassen müssen.

Authentifizierung

Wenn Sie das Authentifizierungsfeature in App Service verwenden (auch als einfache Authentifizierung bezeichnet), leitet Ihre App in der Regel zur Anmeldeseite um. Da App Service den ursprünglichen Hostnamen der Anforderung nicht kennt, erfolgt die Umleitung für den Standarddomänennamen und führt in der Regel zu einem Fehler.

Um die Standardumleitung zu umgehen, können Sie die Authentifizierung so konfigurieren, dass sie einen weitergeleiteter Header überprüft und die Umleitungsdomäne an die ursprüngliche Domäne anpasst. Application Gateway verwendet einen Header namens X-Original-Host. Mithilfe der dateibasierten Konfiguration zum Konfigurieren der Authentifizierung können Sie App Service so konfigurieren, dass er sich an den ursprünglichen Hostnamen anpasst. Fügen Sie der Konfigurationsdatei diese Konfiguration hinzu:

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

ARR-Affinität

Bei Bereitstellungen mit mehreren Instanzen stellt die ARR-Affinität sicher, dass Clientanforderungen für die Lebensdauer der Sitzung an dieselbe Instanz weitergeleitet werden. Die ARR-Affinität funktioniert nicht mit Hostnamenüberschreibungen. Damit die Sitzungsaffinität funktioniert, müssen Sie eine identische benutzerdefinierte Domäne und ein identisches Zertifikat in App Service und in Application Gateway konfigurieren und den Hostnamen nicht überschreiben.

Nächste Schritte

Weitere Informationen zur App Service-Umgebung finden Sie in der Dokumentation zur App Service-Umgebung.

In der Dokumentation zum Azure Web Application-Firewall finden Sie Informationen zur Azure Web Application Firewall in Application Gateway, mit der Sie Ihre App noch sicherer machen können.

Um eine sichere, resiliente Website mit einer benutzerdefinierten Domäne in App Service entweder mittels Azure Front Door oder Application Gateway bereitzustellen, lesen Sie dieses Tutorial.

Teilen über