Exponera Azure Spring Apps via en omvänd proxy

När du är värd för dina appar eller mikrotjänster i Azure Spring Apps vill du inte alltid publicera dem direkt på Internet. Du kanske vill exponera dem via en omvänd proxy i stället. Med den här metoden kan du placera en tjänst framför dina appar. Tjänsten kan definiera övergripande funktioner som WAF-funktioner (Web Application Firewall) för att skydda dina appar, belastningsutjämning, routning, filtrering av begäranden och hastighetsbegränsning.

När du distribuerar en vanlig omvänd proxytjänst som Azure Application Gateway eller Azure Front Door framför Azure Spring Apps bör du se till att dina appar endast kan nås via omvänd proxy. Det här skyddet hjälper till att förhindra att skadliga användare försöker kringgå WAF eller kringgå begränsningar.

Azure DDoS Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Du bör aktivera Azure DDOS Protection i alla virtuella perimeternätverk.

Den här artikeln beskriver hur du framtvingar åtkomstbegränsningar så att program som finns i Azure Spring Apps endast är tillgängliga via en omvänd proxytjänst. Det rekommenderade sättet att tillämpa dessa begränsningar beror på hur du distribuerar din Azure Spring Apps-instans och vilken omvänd proxy du använder. Det finns olika saker att tänka på beroende på om du distribuerar inom eller utanför ett virtuellt nätverk. Den här artikeln innehåller information om fyra scenarier.

• Distribuera Azure Spring Apps i ett virtuellt nätverk och få åtkomst till dina appar privat från nätverket.

  • Du har kontroll över det virtuella nätverk där dina appar körs. Använd inbyggda Azure-nätverksfunktioner som nätverkssäkerhetsgrupper (NSG:er) för att låsa åtkomsten så att endast omvänd proxy tillåts.

  • Du kan exponera dina appar offentligt för Internet med hjälp av Azure Application Gateway och sedan tillämpa lämpliga åtkomstbegränsningar för att låsa den. Den här metoden beskrivs i scenario 1 senare i den här artikeln.

  • Du kan inte använda Azure Front Door direkt eftersom den inte kan nå Azure Spring Apps-instansen i ditt privata virtuella nätverk. Azure Front Door kan endast ansluta till serverdelar via en offentlig IP-adress eller via tjänster som använder en privat slutpunkt. När du har en distribution i flera regioner av Azure Spring Apps och kräver global belastningsutjämning kan du fortfarande exponera dina Azure Spring Apps-instanser via Application Gateway. För att uppnå det här scenariot placerar du Azure Front Door framför Application Gateway. Den här metoden beskrivs i scenario 2 senare i den här artikeln.

• Distribuera Azure Spring Apps utanför ett virtuellt nätverk och publicera dina appar direkt till Internet om du tilldelar dem en slutpunkt.

  • Du styr inte nätverket och du kan inte använda NSG:er för att begränsa åtkomsten. För att endast den omvända proxyn ska få åtkomst till dina appar krävs en metod i själva Azure Spring Apps.

  • Eftersom dina appar kan nås offentligt kan du använda Application Gateway eller Azure Front Door som omvänd proxy. Application Gateway-metoden beskrivs i scenario 3 senare i den här artikeln. Azure Front Door-metoden beskrivs i scenario 4 senare i den här artikeln.

  • Du kan använda en kombination av båda metoderna efter behov. Om du använder både Application Gateway och Azure Front Door använder du samma åtkomstbegränsningar mellan de två omvända proxyservrarna som används i scenario 2.

Scenariojämförelse

Följande tabell innehåller en kort jämförelse av de fyra omvända proxykonfigurationsscenarierna för Azure Spring Apps. Fullständig information om varje scenario finns i lämpligt avsnitt i den här artikeln.

Distribution i ditt virtuella nätverk

När Azure Spring Apps distribueras i ett virtuellt nätverk används två undernät:

• Ett tjänstkörningsundernät som innehåller relevanta nätverksresurser
• Ett undernät för appar som är värd för din kod

Eftersom tjänstkörningsundernätet innehåller lastbalanseraren för att ansluta till dina appar kan du definiera en NSG i det här tjänstkörningsundernätet för att endast tillåta trafik från den omvända proxyn. När du blockerar all annan trafik kan ingen i det virtuella nätverket komma åt dina appar utan att gå igenom den omvända proxyn.

Varje app som du vill exponera via den omvända proxyn ska ha en tilldelad slutpunkt så att den omvända proxyn kan nå appen i det virtuella nätverket. För varje app bör du också mappa de anpassade domäner som används för att undvika att åsidosätta HTTP-huvudet Host i den omvända proxyn och hålla det ursprungliga värdnamnet intakt. Den här metoden undviker problem som brutna cookies eller omdirigerings-URL:er som inte fungerar korrekt. Mer information finns i Bevarande av värdnamn.

Scenario 1: Använd Application Gateway som omvänd proxy

Scenario 1 beskriver hur du exponerar dina appar offentligt för Internet med hjälp av Application Gateway och sedan tillämpar lämpliga åtkomstbegränsningar för att låsa den.

Följande diagram visar arkitekturen för scenario 1:

Ladda ned en Visio-fil med den här arkitekturen.

När Application Gateway finns framför din Azure Spring Apps-instans använder du den tilldelade slutpunkten för Spring Cloud Gateway-appen som serverdelspool. Ett exempel på en slutpunkt: myspringcloudservice-myapp.private.azuremicroservices.io. Slutpunkten matchas mot en privat IP-adress i tjänstkörningsundernätet. För att begränsa åtkomsten kan du därför placera en NSG på tjänstkörningsundernätet med följande regler för inkommande säkerhet (vilket ger neka-regeln den lägsta prioriteten):

Scenario 1-konfigurationen säkerställer att undernätet för tjänstkörning endast tillåter trafik från följande källor:

• Det dedikerade Application Gateway-undernätet
• Appundernätet (dubbelriktad kommunikation mellan de två Azure Spring Apps-undernäten krävs.)
• Azure-lastbalanseraren (vilket är ett allmänt krav för Azure-plattformen)

All annan trafik blockeras.

Scenario 2: Använd både Azure Front Door och Application Gateway som omvänd proxy

Som tidigare nämnts kan du inte placera Azure Front Door direkt framför Azure Spring Apps eftersom det inte kan nå ditt privata virtuella nätverk. (Azure Front Door Standard eller Premium kan ansluta till privata slutpunkter i ett virtuellt nätverk, men Azure Spring Apps erbjuder för närvarande inte stöd för privata slutpunkter.) Om du fortfarande vill använda Azure Front Door, till exempel för att kräva global belastningsutjämning för flera instanser av Azure Spring Apps i olika Azure-regioner, kan du fortfarande exponera dina appar via Application Gateway. För att uppnå det här scenariot placerar du Azure Front Door framför Application Gateway.

Följande diagram visar arkitekturen för scenario 2:

Ladda ned en Visio-fil med den här arkitekturen.

Scenario 2-konfigurationen implementerar åtkomstbegränsningar mellan Application Gateway och Azure Spring Apps på samma sätt som scenario 1. Du placerar en NSG i tjänstkörningsundernätet med lämpliga regler.

I scenario 2 måste du också se till att Application Gateway accepterar trafik som endast kommer från din Azure Front Door-instans. Dokumentationen om Azure Front Door förklarar hur du låser åtkomsten till en serverdel så att endast Azure Front Door-trafik tillåts. När serverdelen är Application Gateway kan du implementera den här begränsningen på följande sätt:

• I Application Gateway-undernätet skapar du en NSG för att endast tillåta trafik som har AzureFrontDoor.Backend tjänsttaggen (inget annat än Azure Front Door kan nå Application Gateway). Se till att även inkludera andra nödvändiga tjänsttaggar enligt beskrivningen i NSG-begränsningar för Application Gateway.
• Skapa en anpassad WAF-regel i Application Gateway för att kontrollera X-Azure-FDID att HTTP-huvudet är inställt på ditt specifika Azure Front Door-instans-ID. Den här metoden säkerställer att ingen annan organisations Azure Front Door-instanser som använder samma IP-intervall kan nå din Application Gateway-instans.

Distribution utanför ditt virtuella nätverk

När du distribuerar Azure Spring Apps utanför ett virtuellt nätverk kan du inte använda inbyggda Azure-nätverksfunktioner eftersom du inte styr nätverket. I stället måste du tillämpa de nödvändiga åtkomstbegränsningarna för själva apparna för att endast tillåta trafik från den omvända proxyn. Om du har många appar kan den här metoden öka komplexiteten och det finns en risk att inte alla appar kan konfigureras på rätt sätt.

Använda Spring Cloud Gateway för att exponera och skydda dina appar

Om du vill ta bort ansvaret för åtkomstkontroll från utvecklarna av enskilda program kan du tillämpa tvärskärningsbegränsningar med hjälp av Spring Cloud Gateway. Spring Cloud Gateway är ett vanligt Spring-projekt som du kan distribuera till Azure Spring Apps precis som andra appar. Genom att använda Spring Cloud Gateway kan du hålla dina egna program privata i Azure Spring Apps-instansen och se till att de endast kan nås via den delade Spring Cloud Gateway-appen. Sedan konfigurerar du den här appen med nödvändiga åtkomstbegränsningar med hjälp av routningspredikat, som är en inbyggd funktion i Spring Cloud Gateway. Routningspredikat kan använda olika attribut för den inkommande HTTP-begäran för att avgöra om begäran ska dirigeras till serverdelsprogrammet eller avvisa den. Predikatet kan använda attribut som klientens IP-adress, begärandemetod eller sökväg, HTTP-huvuden och så vidare.

Det här mönstret används ofta. I den här artikeln förutsätter vi att du exponerar dina program via Spring Cloud Gateway. Vi förväntar oss att du använder dess vägpredikat för att konfigurera nödvändiga åtkomstbegränsningar för att säkerställa att endast begäranden från den omvända proxyn tillåts. Även om du inte använder Spring Cloud Gateway gäller samma allmänna principer. Du måste dock skapa egna funktioner för filtrering av begäranden i dina appar baserat på samma X-Forwarded-For HTTP-huvud som beskrivs senare i den här artikeln.

Att beskriva hur Spring Cloud Gateway fungerar ligger utanför omfånget för den här artikeln. Det är en mycket flexibel tjänst som du kan anpassa via kod eller konfiguration. För att hålla det enkelt beskriver den här artikeln endast en rent konfigurationsdriven metod som inte kräver kodändringar. Du kan implementera den här metoden genom att inkludera den traditionella application.properties filen eller application.yml filen i den distribuerade Spring Cloud Gateway-appen. Du kan också implementera metoden med hjälp av en konfigurationsserver i Azure Spring Apps som externaliserar konfigurationsfilen till en Git-lagringsplats. I följande exempel implementerar application.yml vi metoden med YAML-syntax, men motsvarande application.properties syntax fungerar också.

Dirigera begäranden till dina program

När din app i Azure Spring Apps som standard inte har någon tilldelad slutpunkt eller en anpassad domän som konfigurerats för den, kan den inte nås utifrån. När en app registreras med Spring Cloud Service Registry kan Spring Cloud Gateway identifiera appen så att den kan använda routningsregler för att vidarebefordra trafik till rätt målapp.

Därför är den enda app som behöver en slutpunkt tilldelad till den i Azure Spring Apps din Spring Cloud Gateway-app. Den här slutpunkten gör att den kan nås utifrån. Du bör inte tilldela en slutpunkt till andra appar. Annars kan apparna nås direkt i stället för via Spring Cloud Gateway, vilket i sin tur gör att den omvända proxyn kringgås.

Ett enkelt sätt att exponera alla registrerade appar via Spring Cloud Gateway är att använda identifieringsklienten för routningsdefinition på följande sätt:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Du kan också selektivt exponera vissa appar via Spring Cloud Gateway genom att definiera appspecifika vägar:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

Med både metoden för identifieringslokaliserare och explicita vägdefinitioner kan du använda vägpredikat för att avvisa ogiltiga begäranden. I det här fallet använder vi den funktionen för att blockera begäranden som inte kommer från den förväntade omvända proxyn som finns framför Azure Spring Apps.

Begränsa åtkomsten med HTTP-huvudet X-Forwarded-For

När du distribuerar en app till Azure Spring Apps ansluter INTE HTTP-klienten eller omvänd proxy direkt till appen. Nätverkstrafiken går först igenom en intern ingresskontrollant.

På grund av den extra tjänsten är IP-adressen för direktnätverksklienten alltid en intern Azure Spring Apps-komponent. IP-adressen är aldrig den logiska klienten som den omvända proxy som du förväntar dig att anropa din app. Du kan inte använda klientens IP-adress för åtkomstbegränsningar. Du kan inte heller använda Spring Cloud Gateways inbyggda vägpredikat för filtrering av begäranden eftersom klientens IP-adress RemoteAddr används som standard.

Som tur är lägger Azure Spring Apps alltid till den logiska klientens IP-adress i X-Forwarded-For HTTP-huvudet på begäran i din app. Det sista värdet (höger-mest) för X-Forwarded-For huvudet innehåller alltid IP-adressen för den logiska klienten.

Om du vill filtrera begäranden baserat på X-Forwarded-For rubriken kan du använda det inbyggda XForwarded Remote Addr vägpredikatet. Med det här predikatet kan du konfigurera en lista över IP-adresser eller IP-intervall för den omvända proxyn som tillåts som det mest högra värdet.

Konfigurera appen så att den ser rätt värdnamn och begärande-URL

När du använder Spring Cloud Gateway finns det en viktig faktor att tänka på. Spring Cloud Gateway anger HTTP-huvudet Host på den utgående begäran till den interna IP-adressen för din appinstans, till exempel Host: 10.2.1.15:1025. Begärans värdnamn som programkoden ser är inte längre det ursprungliga värdnamnet för den begäran som webbläsaren skickade, till exempel contoso.com. I vissa fall kan det här resultatet leda till problem som att brutna cookies eller omdirigerings-URL:er inte fungerar korrekt. Mer information om dessa typer av problem och hur du konfigurerar en omvänd proxytjänst som Application Gateway eller Azure Front Door för att undvika dem finns i Bevarande av värdnamn.

Spring Cloud Gateway tillhandahåller det ursprungliga värdnamnet i Forwarded rubriken. Den anger även andra rubriker som X-Forwarded-Port, X-Forwarded-Protooch X-Forwarded-Prefix så att ditt program kan använda dem för att rekonstruera den ursprungliga begärande-URL:en. I Spring Framework-program kan du uppnå den här konfigurationen automatiskt genom att ange server.forward-headers-strategy inställningen till FRAMEWORK i dina programegenskaper. (Ange inte det här värdet till NATIVE. Annars används andra rubriker som inte tar hänsyn till det nödvändiga X-Forwarded-Prefix huvudet.) Mer information finns i Köra bakom en klientdelsproxyserver. Med den här konfigurationen tar metoden HttpServletRequest.getRequestURL hänsyn till alla dessa huvuden och returnerar den exakta begärande-URL:en som skickas av webbläsaren.

Scenario 3: Använda Application Gateway med Spring Cloud Gateway

Scenario 3 beskriver hur du använder Application Gateway som omvänd proxy för offentligt nåbara appar via en Spring Cloud Gateway-slutpunkt.

Följande diagram visar arkitekturen för scenario 3:

Ladda ned en Visio-fil med den här arkitekturen.

När Application Gateway finns framför din Azure Spring Apps-instans använder du den tilldelade slutpunkten för Spring Cloud Gateway-appen som serverdelspool. Ett exempel på en slutpunkt: myspringcloudservice-mygateway.azuremicroservices.io. Eftersom Azure Spring Apps distribueras utanför ett virtuellt nätverk matchas den här URL:en till en offentlig IP-adress. När serverdelspoolen är en offentlig slutpunkt använder Application Gateway sin offentliga IP-adress för klientdelen för att nå serverdelstjänsten.

Om du bara vill tillåta att begäranden från din Application Gateway-instans når Spring Cloud Gateway kan du konfigurera XForwarded Remote Addr vägpredikatet. Konfigurera predikatet så att endast begäranden från den dedikerade offentliga IP-adressen för din Application Gateway tillåts enligt följande exempel:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Scenario 4: Använda Azure Front Door med Spring Cloud Gateway

Scenario 4 beskriver hur du använder Azure Front Door som omvänd proxy för offentligt nåbara appar via en Spring Cloud Gateway-slutpunkt.

Följande diagram visar arkitekturen för scenario 4:

Ladda ned en Visio-fil med den här arkitekturen.

Precis som scenario 3 använder den här konfigurationen den offentliga URL:en för Spring Cloud Gateway-appen som serverdelspool eller ursprung i Azure Front Door. Ett exempel på en slutpunkt: https://myspringcloudservice-mygateway.azuremicroservices.io.

Eftersom Azure Front Door är en global tjänst med många gränsplatser använder den många IP-adresser för att kommunicera med sin serverdelspool. Azure Front Door-dokumentationen beskriver hur du låser åtkomsten till en serverdel så att endast Azure Front Door-trafik tillåts. I det här scenariot styr du dock inte det Azure-nätverk där dina appar distribueras. Tyvärr kan du inte använda AzureFrontDoor.Backend tjänsttaggen för att få en fullständig lista över utgående Ip-adresser för Azure Front Door som garanterat är aktuella. I stället måste du ladda ned Azure IP-intervall och tjänsttaggar, hitta AzureFrontDoor.Backend avsnittet och kopiera alla IP-intervall från matrisen addressPrefixes till XForwarded Remote Addr vägpredikatkonfigurationen.

Eftersom Ip-intervallen för Azure Front Door delas med andra organisationer måste du också se till att du låser åtkomsten till endast din specifika Azure Front Door-instans, baserat på X-Azure-FDID HTTP-huvudet som innehåller din unika Front Door ID. Du kan begränsa åtkomsten med hjälp Header av vägpredikatet, som avvisar en begäran om inte ett angivet HTTP-huvud har ett visst värde.

I det här scenariot kan din Spring Cloud Gateway-vägpredikatkonfiguration se ut som i följande exempel:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "00112233-4455-6677-8899-aabbccddeeff"

Deltagare

Microsoft underhåller det här innehållet. Följande deltagare utvecklade det ursprungliga innehållet.

Huvudförfattare:

• Jelle Druyts | Huvudkundtekniker

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Referensarkitektur för Azure Spring Apps
• Kundansvar för att köra Azure Spring Apps i Azure Virtual Networks

Relaterade resurser

• Bevarande av värdnamn
• Alternativ för belastningsutjämning
• Arkitekturformat för mikrotjänster