Integration av Application Gateway

Tre varianter av Azure App Service kräver en något annorlunda konfiguration av integreringen med Azure Application Gateway. Varianterna omfattar vanlig App Service (kallas även multitenant), en intern lastbalanserare (ILB) App Service-miljön och en extern App Service-miljön.

Den här artikeln beskriver hur du konfigurerar Application Gateway med App Service (multitenant) med hjälp av tjänstslutpunkter för att skydda trafiken. I artikeln beskrivs även överväganden kring användning av privata slutpunkter och integrering med ILB och externa App Service-miljön. Slutligen beskriver artikeln hur du anger åtkomstbegränsningar på en SCM-webbplats (Source Control Manager).

Integrering med App Service (multitenant)

App Service (multitenant) har en offentlig internetuppkopplad slutpunkt. Genom att använda tjänstslutpunkter kan du endast tillåta trafik från ett specifikt undernät i ett virtuellt Azure-nätverk och blockera allt annat. I följande scenario använder du den här funktionen för att säkerställa att en App Service-instans endast kan ta emot trafik från en specifik programgateway.

Det finns två delar i den här konfigurationen, förutom att skapa App Service-instansen och programgatewayen. Den första delen är att aktivera tjänstslutpunkter i undernätet för det virtuella nätverk där programgatewayen distribueras. Tjänstslutpunkter ser till att all nätverkstrafik som lämnar undernätet mot App Service taggas med det specifika undernäts-ID:t.

Den andra delen är att ange en åtkomstbegränsning för den specifika webbappen för att säkerställa att endast trafik som är taggad med det här specifika undernäts-ID:t tillåts. Du kan konfigurera åtkomstbegränsningen med hjälp av olika verktyg, beroende på vad du föredrar.

Konfigurera tjänster med hjälp av Azure-portalen

Med Azure-portalen följer du fyra steg för att skapa och konfigurera konfigurationen av App Service och Application Gateway. Om du har befintliga resurser kan du hoppa över de första stegen.

1. Skapa en App Service-instans med hjälp av någon av snabbstarterna i App Service-dokumentationen. Ett exempel är .NET Core-snabbstarten.
2. Skapa en programgateway med hjälp av portalens snabbstart, men hoppa över avsnittet om att lägga till serverdelsmål.
3. Konfigurera App Service som en serverdel i Application Gateway, men hoppa över avsnittet om att begränsa åtkomsten.
4. Skapa åtkomstbegränsningen med hjälp av tjänstslutpunkter.

Nu kan du komma åt App Service via Application Gateway. Om du försöker komma åt App Service direkt bör du få ett 403 HTTP-fel som säger att webbappen har blockerat din åtkomst.

Konfigurera tjänster med hjälp av en Azure Resource Manager-mall

Azure Resource Manager-distributionsmallen skapar ett fullständigt scenario. Scenariot består av en App Service-instans som är låst med tjänstslutpunkter och en åtkomstbegränsning för att endast ta emot trafik från Application Gateway. Mallen innehåller många smarta standardvärden och unika postfix som lagts till i resursnamnen för att hålla det enkelt. Om du vill åsidosätta dem måste du klona lagringsplatsen eller ladda ned mallen och redigera den.

Om du vill använda mallen kan du använda knappen Distribuera till Azure i beskrivningen av mallen. Du kan också använda lämplig PowerShell- eller Azure CLI-kod.

Konfigurera tjänster med hjälp av Azure CLI

Azure CLI-exemplet skapar en App Service-instans som är låst med tjänstslutpunkter och en åtkomstbegränsning för att endast ta emot trafik från Application Gateway. Om du bara behöver isolera trafik till en befintlig App Service-instans från en befintlig programgateway använder du följande kommando:

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

I standardkonfigurationen säkerställer kommandot konfigurationen av tjänstslutpunktskonfigurationen i undernätet och åtkomstbegränsningen i App Service.

Överväganden för att använda privata slutpunkter

Som ett alternativ till tjänstslutpunkter kan du använda privata slutpunkter för att skydda trafiken mellan Application Gateway och App Service (multitenant). Du måste se till att Application Gateway kan använda DNS för att matcha apptjänstapparnas privata IP-adress. Du kan också använda den privata IP-adressen i serverdelspoolen och åsidosätta värdnamnet i HTTP-inställningarna.

Application Gateway cachelagrar DNS-sökningsresultatet. Om du använder fullständigt kvalificerade domännamn (FQDN) och förlitar dig på DNS-sökning för att hämta den privata IP-adressen kan du behöva starta om programgatewayen om DNS-uppdateringen eller länken till en privat Dns-zon i Azure skedde efter att du konfigurerat serverdelspoolen.

Starta om programgatewayen genom att stoppa och starta den med hjälp av Azure CLI:

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

Överväganden för en ILB-App Service-miljön

En ILB-App Service-miljön exponeras inte för Internet. Trafiken mellan instansen och en programgateway är redan isolerad till det virtuella nätverket. Information om hur du konfigurerar en ILB-App Service-miljön och integrerar den med en programgateway med hjälp av Azure-portalen finns i instruktioner.

Om du vill se till att endast trafik från Application Gateway-undernätet når App Service-miljön kan du konfigurera en nätverkssäkerhetsgrupp (NSG) som påverkar alla webbappar i App Service-miljön. För NSG kan du ange IP-intervallet för undernätet och valfritt portarna (80/443). För att App Service-miljön ska fungera korrekt kontrollerar du att du inte åsidosätter de NSG-regler som krävs.

Om du vill isolera trafik till en enskild webbapp måste du använda IP-baserade åtkomstbegränsningar eftersom tjänstslutpunkter inte fungerar med en App Service-miljön. IP-adressen ska vara den privata IP-adressen för programgatewayen.

Överväganden för en extern App Service-miljön

En extern App Service-miljön har en offentlig lastbalanserare som App Service för flera klientorganisationer. Tjänstslutpunkter fungerar inte för en App Service-miljön. Därför måste du använda IP-baserade åtkomstbegränsningar med hjälp av den offentliga IP-adressen för programgatewayen. Om du vill skapa en extern App Service-miljön med hjälp av Azure-portalen kan du följa den här snabbstarten.

Överväganden för en Kudu/SCM-webbplats

SCM-webbplatsen, även kallad Kudu, är en administratörswebbplats som finns för varje webbapp. Det går inte att använda omvänd proxy för SCM-webbplatsen. Du vill förmodligen också låsa den till enskilda IP-adresser eller ett specifikt undernät.

Om du vill använda samma åtkomstbegränsningar som huvudwebbplatsen kan du ärva inställningarna med hjälp av följande kommando:

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

Om du vill lägga till enskilda åtkomstbegränsningar för SCM-webbplatsen kan du använda --scm-site flaggan:

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

Överväganden för att använda standarddomänen

Att konfigurera Application Gateway för att åsidosätta värdnamnet och använda standarddomänen för App Service (vanligtvis azurewebsites.net) är det enklaste sättet att konfigurera integreringen. Det kräver inte att du konfigurerar en anpassad domän och ett certifikat i App Service.

I den här artikeln beskrivs allmänna överväganden för att åsidosätta det ursprungliga värdnamnet. I App Service finns det två scenarier där du måste vara uppmärksam på den här konfigurationen.

Autentisering

När du använder autentiseringsfunktionen i App Service (kallas även Easy Auth) omdirigeras appen vanligtvis till inloggningssidan. Eftersom App Service inte känner till det ursprungliga värdnamnet för begäran görs omdirigeringen på standarddomännamnet och resulterar vanligtvis i ett fel.

Om du vill kringgå standardomdirigeringen kan du konfigurera autentisering för att inspektera ett vidarebefordrat huvud och anpassa omdirigeringsdomänen till den ursprungliga domänen. Application Gateway använder en rubrik med namnet X-Original-Host. Genom att använda filbaserad konfiguration för att konfigurera autentisering kan du konfigurera App Service så att det anpassas till det ursprungliga värdnamnet. Lägg till den här konfigurationen i konfigurationsfilen:

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

ARR-tillhörighet

I distributioner med flera instanser säkerställer ARR-tillhörighet att klientbegäranden dirigeras till samma instans under sessionens livslängd. ARR-tillhörighet fungerar inte med åsidosättningar av värdnamn. För att sessionstillhörighet ska fungera måste du konfigurera en identisk anpassad domän och ett certifikat i App Service och i Application Gateway och inte åsidosätta värdnamnet.

Nästa steg

Mer information om App Service-miljön finns i dokumentationen för App Service-miljön.

Om du vill skydda webbappen ytterligare kan du hitta information om Azure Web Application Firewall på Application Gateway i dokumentationen för Azure Web Application Firewall.

Information om hur du distribuerar en säker och elastisk webbplats med en anpassad domän i App Service med hjälp av antingen Azure Front Door eller Application Gateway finns i den här självstudien.