Freigeben über

Was ist Azure Application Gateway Integration mit Azure App Service?

Dieser Artikel bietet eine Übersicht über die Konfiguration von Azure Application Gateway mit Azure App Service mithilfe privater Endpunkte zum Sichern des Datenverkehrs. Überprüfen Sie Überlegungen zur Verwendung von Dienstendpunkten und zur Integration in eine interne oder externe App Service Environment. Legen Sie Zugriffsbeschränkungen für eine Website des Quellcodeverwaltungs-Managers (Source Control Manager, SCM) fest.

Integration mit App Service

Sie können einen privaten Endpunkt verwenden, um den Datenverkehr zwischen Application Gateway und Ihrer App Service-App zu sichern. Sie müssen sicherstellen, dass das Anwendungsgateway das Domain Name System (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.

Diagramm des Datenverkehrs, der über einen privaten Endpunkt zu einem Application-Gateway und weiter zu App Service-Apps fließt.

Application Gateway speichert die Ergebnisse der DNS-Suche zwischen. Wenn Sie vollqualifizierte Domänennamen (FQDNs) verwenden und die DNS-Suche verwenden, um die private IP-Adresse abzurufen, müssen Sie möglicherweise das Anwendungsgateway neu starten. Ein Neustart ist erforderlich, wenn das DNS-Update oder der Link zu einer Azure privaten DNS-Zone erfolgt, nachdem Sie den Back-End-Pool konfiguriert haben.

Um das Anwendungsgateway neu zu starten, beenden Sie es, und starten Sie es mit den folgenden Azure CLI Befehlen. Ersetzen Sie die Namen Ihrer lokalen Ressourcen für alle <Platzhalter>-Werte in den Befehlen.

az network application-gateway stop --resource-group <your-resource-group> --name <your-application-gateway>
az network application-gateway start --resource-group <your-resource-group> --name <your-application-gateway>

Erfahren Sie mehr über das Konfigurieren einer App Service-App mit privatem Endpunkt.

Überlegungen zur Verwendung von Dienstendpunkten

Als Alternative zur Verwendung privater Endpunkte können Sie Dienstendpunkte verwenden, um den Datenverkehr vom Anwendungsgateway zu sichern. Mithilfe von service-Endpunkten können Sie den Datenverkehr nur von einem bestimmten Subnetz innerhalb eines Azure virtuellen Netzwerks zulassen und alles andere blockieren. Im folgenden Szenario verwenden Sie diese Funktion, um sicherzustellen, dass App-Dienst-Apps Nur von einem bestimmten Anwendungsgateway Datenverkehr empfangen können.

Diagramm des Internets, das an ein Anwendungsgateway in einem virtuellen Netzwerk fließt, und dann über eine Dienstendpunktfirewall zu App Service-Apps.

Diese Konfiguration umfasst zwei Teile, neben dem Erstellen der App Service-App-Instanz und des Anwendungsgateways.

  • Der erste Teil ermöglicht Dienstendpunkte im Subnetz des virtuellen Netzwerks, in dem das Anwendungsgateway bereitgestellt wird. Dienstendpunkte stellen sicher, dass der gesamte Netzwerkdatenverkehr, der das Subnetz in Richtung App Service verlässt, mit der spezifischen Subnetz-ID markiert ist.

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

Im Azure-Portal führen Sie vier Schritte aus, um die Integration von App Service und Anwendungsgateway zu erstellen und zu konfigurieren. Wenn Sie über vorhandene Ressourcen verfügen, können Sie die ersten und zweiten Schritte überspringen.

  1. Erstellen Sie eine App Service-App mithilfe einer der Schnellstarts in der App Service-Dokumentation. Ein Beispiel ist die .NET Core-Schnellstartanleitung.
  2. Erstellen Sie ein Anwendungsgateway mithilfe der Portalschnellstartanleitung, überspringen Sie jedoch den Abschnitt zum Hinzufügen von Back-End-Zielen.
  3. Konfigurieren Sie App Service als Back-End im Anwendungsgateway, überspringen Sie jedoch den Abschnitt zum Einschränken des Zugriffs.
  4. Erstellen Sie die Zugriffsbeschränkung mithilfe von Dienstendpunkten.

Sie können jetzt über Application Gateway auf App Service zugreifen. Wenn Sie versuchen, direkt auf Den App-Dienst zuzugreifen, erwarten Sie einen 403 HTTP-Fehler, der besagt, dass die Web-App Ihren Zugriff blockiert.

Überlegungen zu einer internen App Service Environment

Ein internes App Service Environment ist dem Internet nicht ausgesetzt. Der Datenverkehr zwischen der Umgebung und einem Anwendungsgateway ist bereits auf das virtuelle Netzwerk isoliert. Sie können eine interne Umgebung konfigurieren und in ein Anwendungsgateway integrieren mithilfe des Azure-Portals.

Wenn Sie sicherstellen möchten, dass nur datenverkehr vom Subnetz des Anwendungsgateways die App Service Environment erreicht, können Sie eine Netzwerksicherheitsgruppe konfigurieren, die sich auf alle Web-Apps in der Umgebung auswirkt. Für die Netzwerksicherheitsgruppe können Sie den Subnetz-IP-Bereich und optional die Ports (80/443) angeben.

Um den Datenverkehr für eine einzelne Web-App zu isolieren, müssen Sie IP-basierte Zugriffsbeschränkungen verwenden, da Dienstendpunkte nicht mit einem App Service Environment funktionieren. Bei der IP-Adresse muss es sich um die private IP-Adresse des Anwendungsgateways handeln.

Überlegungen zu einem externen App Service Environment

Eine externe App Service-Umgebung verfügt über einen öffentlichen Lastenausgleich wie mandantenfähige App Service-Apps. Dienstendpunkte funktionieren für eine externe App Service Environment nicht. In einem App Service Environment können Sie IP-basierte Zugriffsbeschränkungen mithilfe der öffentlichen IP-Adresse des Anwendungsgateways anwenden. Zum Erstellen einer externen App Service Environment im Azure-Portal können Sie ein quickstart verwenden.

Sie können auch private Endpunkte zu Apps hinzufügen, die in einer externen App Service-Umgebung gehostet werden.

Ü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 dieselben Zugriffsbeschränkungen wie die Hauptwebsite verwenden möchten, können Sie die Einstellungen mit dem folgenden Azure CLI Befehl erben:

az webapp config access-restriction set --resource-group <your-resource-group> --name <your-web-app> --use-same-restrictions-for-scm-site

Wenn Sie einzelne Zugriffsbeschränkungen für die SCM-Website hinzufügen möchten, können Sie das --scm-site Flag mit dem Befehl verwenden:

az webapp config access-restriction add --resource-group <your-resource-group> --name <your-web-app> --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Überlegungen zur Verwendung der Standarddomäne

Sie können das Application Gateway so konfigurieren, dass es den Hostnamen durch die Standarddomäne des App Service ersetzt (in der Regel azurewebsites.net). Dieser Ansatz ist die einfachste Möglichkeit zur Integration, da die Konfiguration einer benutzerdefinierten Domäne und eines benutzerdefinierten Zertifikats in App Service nicht erforderlich ist.

Der Erhaltungsprozess für Hostnamen beschreibt die allgemeinen Überlegungen zum Überschreiben des ursprünglichen Hostnamens. Beachten Sie in App Service die folgenden Überlegungen zur Authentifizierung und Sitzungsaffinität.

Authentifizierung (Easy Auth)

Wenn Sie das Authentifizierungsfeature in App Service (auch als Easy Auth bezeichnet) verwenden, 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. Das Anwendungsgateway verwendet einen Header mit dem Namen X-Original-Host. Mithilfe der dateibasierten Konfiguration zur Angabe der Authentifizierung können Sie den App-Dienst so konfigurieren, dass er an den ursprünglichen Hostnamen angepasst wird.

Fügen Sie der Konfigurationsdatei diese Konfiguration hinzu:

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

Sitzungsaffinität

Wenn Sie die Einstellung "Sitzungsaffinität" in Bereitstellungen mit mehreren Instanzen angeben, können Sie sicherstellen, dass Clientanforderungen für die Lebensdauer der Sitzung an dieselbe Instanz weitergeleitet werden. Sie können die Sitzungsaffinität so konfigurieren, dass die Cookiedomäne an den eingehenden Header vom Reverseproxy angepasst wird.

Wenn Sie das Session Affinity ProxySetting auf true festlegen, sucht Session Affinity nach dem X-Original-Host oder X-Forwarded-Host-Header. Sie passt die Cookie-Domäne an die Im Header gefundene Domäne an. Als empfohlene Vorgehensweise beim Aktivieren des Sitzungsaffinitätsproxys konfigurieren Sie Ihre Zugriffsbeschränkungen auf der Website, um sicherzustellen, dass Datenverkehr von Ihrem Reverseproxy stammt.

Sie können die Einstellung clientAffinityProxyEnabled auch mit dem folgenden Azure CLI Befehl konfigurieren:

az resource update --resource-group <your-resource-group> --name <your-web-app> --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

Verwandte Inhalte

  • Last updated on