Azure Spring Apps beschikbaar maken via een omgekeerde proxy

Wanneer u uw apps of microservices in Azure Spring Apps host, wilt u ze niet altijd rechtstreeks publiceren op internet. U wilt ze mogelijk beschikbaar maken via een omgekeerde proxy. Met deze aanpak kunt u een service plaatsen vóór uw apps. De service kan geavanceerde functionaliteit definiëren, zoals WAF-mogelijkheden (Web Application Firewall) om uw apps, taakverdeling, routering, aanvraagfiltering en snelheidsbeperking te beveiligen.

Wanneer u een algemene omgekeerde proxyservice implementeert, zoals Azure-toepassing Gateway of Azure Front Door vóór Azure Spring Apps, moet u ervoor zorgen dat uw apps alleen kunnen worden bereikt via de omgekeerde proxy. Deze beveiliging helpt voorkomen dat kwaadwillende gebruikers proberen de WAF te omzeilen of beperkingslimieten te omzeilen.

Azure DDoS Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. Schakel Azure DDOS Protection in voor elk virtueel perimeternetwerk.

In dit artikel wordt beschreven hoe u toegangsbeperkingen kunt afdwingen, zodat toepassingen die worden gehost in Azure Spring Apps alleen toegankelijk zijn via een omgekeerde proxyservice. De aanbevolen manier om deze beperkingen af te dwingen, is afhankelijk van hoe u uw Azure Spring Apps-exemplaar implementeert en welke omgekeerde proxy u gebruikt. De verschillende punten die u moet overwegen, is afhankelijk van of u binnen of buiten een virtueel netwerk implementeert. Dit artikel bevat informatie over vier scenario's.

• Implementeer Azure Spring Apps in een virtueel netwerk en open uw apps privé vanuit het netwerk.

  • U hebt controle over het virtuele netwerk waarin uw apps worden uitgevoerd. Gebruik systeemeigen Azure-netwerkfuncties zoals netwerkbeveiligingsgroepen (NSG's) om de toegang te vergrendelen om alleen uw omgekeerde proxy toe te staan.

  • U kunt uw apps openbaar beschikbaar maken op internet met behulp van Azure-toepassing Gateway en vervolgens de juiste toegangsbeperkingen toepassen om deze te vergrendelen. Deze benadering wordt verderop in dit artikel beschreven in Scenario 1.

  • U kunt Azure Front Door niet rechtstreeks gebruiken omdat het azure Spring Apps-exemplaar niet kan bereiken in uw virtuele privénetwerk. Azure Front Door kan alleen verbinding maken met back-ends via een openbaar IP-adres of via services die gebruikmaken van een privé-eindpunt. Wanneer u een implementatie met meerdere regio's van Azure Spring Apps hebt en globale taakverdeling vereist, kunt u uw Azure Spring Apps-exemplaren nog steeds beschikbaar maken via Application Gateway. Om dit scenario te bereiken, plaatst u Azure Front Door voor Application Gateway. Deze benadering wordt verderop in dit artikel beschreven in Scenario 2.

• Implementeer Azure Spring Apps buiten een virtueel netwerk en publiceer uw apps rechtstreeks op internet als u ze een eindpunt toewijst.

  • U beheert het netwerk niet en u kunt geen NSG's gebruiken om de toegang te beperken. Alleen de omgekeerde proxy toegang tot uw apps toestaan, vereist een benadering binnen Azure Spring Apps zelf.

  • Omdat uw apps openbaar bereikbaar zijn, kunt u Application Gateway of Azure Front Door gebruiken als omgekeerde proxy. De Application Gateway-benadering wordt verderop in dit artikel beschreven in Scenario 3. De Azure Front Door-benadering wordt verderop in dit artikel beschreven in Scenario 4.

  • U kunt indien nodig een combinatie van beide benaderingen gebruiken. Als u zowel Application Gateway als Azure Front Door gebruikt, gebruikt u dezelfde toegangsbeperkingen tussen de twee omgekeerde proxy's die worden gebruikt in Scenario 2.

Scenariovergelijking

De volgende tabel bevat een korte vergelijking van de vier configuratiescenario's voor omgekeerde proxy's voor Azure Spring Apps. Raadpleeg de juiste sectie van dit artikel voor meer informatie over elk scenario.

Implementatie binnen uw virtuele netwerk

Wanneer Azure Spring Apps wordt geïmplementeerd in een virtueel netwerk, worden er twee subnetten gebruikt:

• Een serviceruntimesubnet dat de relevante netwerkbronnen bevat
• Een app-subnet dat als host fungeert voor uw code

Omdat het subnet van de serviceruntime de load balancer bevat voor het maken van verbinding met uw apps, kunt u een NSG definiëren op dit subnet van de serviceruntime om alleen verkeer van uw omgekeerde proxy toe te staan. Wanneer u al het andere verkeer blokkeert, heeft niemand in het virtuele netwerk toegang tot uw apps zonder de omgekeerde proxy te doorlopen.

Elke app die u beschikbaar wilt maken via uw omgekeerde proxy, moet een toegewezen eindpunt hebben, zodat de omgekeerde proxy de app in het virtuele netwerk kan bereiken. Voor elke app moet u ook de aangepaste domeinen toewijzen die worden gebruikt om te voorkomen dat de HTTP-header Host in de omgekeerde proxy wordt overschreven en de oorspronkelijke hostnaam intact blijft. Deze methode voorkomt problemen zoals verbroken cookies of omleidings-URL's die niet goed werken. Zie Behoud van hostnamen voor meer informatie.

Scenario 1: Application Gateway gebruiken als omgekeerde proxy

In scenario 1 wordt beschreven hoe u uw apps openbaar beschikbaar maakt op internet met behulp van Application Gateway en vervolgens de juiste toegangsbeperkingen toepast om deze te vergrendelen.

In het volgende diagram ziet u de architectuur voor Scenario 1:

Een Visio-bestand van deze architectuur downloaden.

Wanneer Application Gateway zich voor uw Azure Spring Apps-exemplaar bevindt, gebruikt u het toegewezen eindpunt van de Spring Cloud Gateway-app als back-endpool. Een voorbeeldeindpunt is myspringcloudservice-myapp.private.azuremicroservices.io. Het eindpunt wordt omgezet in een privé-IP-adres in het subnet van de serviceruntime. Als u de toegang wilt beperken, kunt u daarom een NSG in het subnet van de serviceruntime plaatsen met de volgende inkomende beveiligingsregels (waardoor de regel Weigeren de laagste prioriteit krijgt):

De configuratie scenario 1 zorgt ervoor dat het subnet van de serviceruntime alleen verkeer vanaf de volgende bronnen toestaat:

• Het toegewezen Application Gateway-subnet
• Het subnet apps (bidirectionele communicatie tussen de twee Azure Spring Apps-subnetten is vereist.)
• De Azure Load Balancer (wat een algemene Azure-platformvereiste is)

Al het andere verkeer wordt geblokkeerd.

Scenario 2: Zowel Azure Front Door als Application Gateway gebruiken als de omgekeerde proxy

Zoals eerder vermeld, kunt u Azure Front Door niet rechtstreeks voor Azure Spring Apps plaatsen, omdat deze niet in uw particuliere virtuele netwerk kan worden bereikt. (Azure Front Door Standard of Premium kan verbinding maken met privé-eindpunten in een virtueel netwerk, maar Azure Spring Apps biedt momenteel geen ondersteuning voor privé-eindpunten.) Als u Azure Front Door nog steeds wilt gebruiken, zoals het vereisen van wereldwijde taakverdeling voor meerdere exemplaren van Azure Spring Apps in verschillende Azure-regio's, kunt u uw apps nog steeds beschikbaar maken via Application Gateway. Om dit scenario te bereiken, plaatst u Azure Front Door voor Application Gateway.

In het volgende diagram ziet u de architectuur voor Scenario 2:

Een Visio-bestand van deze architectuur downloaden.

Met de configuratie scenario 2 worden toegangsbeperkingen geïmplementeerd tussen Application Gateway en Azure Spring Apps op dezelfde manier als scenario 1. U plaatst een NSG op het subnet van de serviceruntime met de juiste regels.

In scenario 2 moet u er ook voor zorgen dat Application Gateway verkeer accepteert dat alleen afkomstig is van uw Azure Front Door-exemplaar. In de Documentatie van Azure Front Door wordt uitgelegd hoe u de toegang tot een back-end kunt vergrendelen om alleen Verkeer van Azure Front Door toe te staan. Wanneer de back-end Application Gateway is, kunt u deze beperking als volgt implementeren:

• Maak in het Application Gateway-subnet een NSG om alleen verkeer met de AzureFrontDoor.Backend servicetag toe te staan (niets behalve Azure Front Door kan Application Gateway bereiken). Zorg ervoor dat u ook andere vereiste servicetags opneemt, zoals beschreven in NSG-beperkingen voor Application Gateway.
• Maak een aangepaste WAF-regel in Application Gateway om te controleren of de X-Azure-FDID HTTP-header is ingesteld op uw specifieke Azure Front Door-exemplaar-id. Deze methode zorgt ervoor dat er geen Azure Front Door-exemplaren van een andere organisatie die gebruikmaken van dezelfde IP-bereiken uw Application Gateway-exemplaar kunnen bereiken.

Implementatie buiten uw virtuele netwerk

Wanneer u Azure Spring Apps buiten een virtueel netwerk implementeert, kunt u geen systeemeigen Azure-netwerkfuncties gebruiken omdat u het netwerk niet bepaalt. In plaats daarvan moet u de benodigde toegangsbeperkingen toepassen op de apps zelf om alleen verkeer vanaf de omgekeerde proxy toe te staan. Als u veel apps hebt, kan deze aanpak complexiteit toevoegen en er is een risico dat niet elke app op de juiste manier kan worden geconfigureerd.

Spring Cloud Gateway gebruiken om uw apps beschikbaar te maken en te beveiligen

Als u de verantwoordelijkheid voor toegangsbeheer van de ontwikkelaars van afzonderlijke toepassingen wilt verwijderen, kunt u kruislingse beperkingen toepassen met behulp van Spring Cloud Gateway. Spring Cloud Gateway is een veelgebruikt Spring-project dat u kunt implementeren in Azure Spring Apps, net als elke andere app. Door Spring Cloud Gateway te gebruiken, kunt u uw eigen toepassingen privé houden binnen het Azure Spring Apps-exemplaar en ervoor zorgen dat deze alleen toegankelijk is via de gedeelde Spring Cloud Gateway-app. Vervolgens configureert u deze app met de benodigde toegangsbeperkingen met behulp van routepredicaten. Dit is een ingebouwde functie van Spring Cloud Gateway. Routepredicaten kunnen verschillende kenmerken van de binnenkomende HTTP-aanvraag gebruiken om te bepalen of de aanvraag naar de back-endtoepassing moet worden gerouteerd of geweigerd. Het predicaat kan gebruikmaken van kenmerken zoals het IP-adres van de client, de aanvraagmethode of het pad, HTTP-headers, enzovoort.

Dit patroon wordt vaak gebruikt. In dit artikel wordt ervan uitgegaan dat u uw toepassingen beschikbaar maakt via Spring Cloud Gateway. We verwachten dat u de routepredicaten gebruikt om de benodigde toegangsbeperkingen in te stellen om ervoor te zorgen dat alleen aanvragen van de omgekeerde proxy zijn toegestaan. Zelfs als u Geen Spring Cloud Gateway gebruikt, zijn dezelfde algemene principes van toepassing. U moet echter uw eigen aanvraagfiltermogelijkheden inbouwen in uw apps op basis van dezelfde X-Forwarded-For HTTP-header die verderop in dit artikel wordt besproken.

Een beschrijving van de werking van Spring Cloud Gateway valt buiten het bereik van dit artikel. Het is een zeer flexibele service die u kunt aanpassen via code of configuratie. Om het eenvoudig te houden, beschrijft dit artikel alleen een puur configuratiegestuurde benadering waarvoor geen codewijzigingen nodig zijn. U kunt deze aanpak implementeren door het traditionele application.properties bestand of application.yml bestand op te slaan in de geïmplementeerde Spring Cloud Gateway-app. U kunt de aanpak ook implementeren met behulp van een configuratieserver in Azure Spring Apps die het configuratiebestand extern maakt in een Git-opslagplaats. In de volgende voorbeelden implementeren we de application.yml benadering met YAML-syntaxis, maar de equivalente application.properties syntaxis werkt ook.

Aanvragen routeren naar uw toepassingen

Wanneer uw app in Azure Spring Apps standaard geen eindpunt heeft toegewezen of als er een aangepast domein is geconfigureerd, is deze niet bereikbaar vanaf de buitenkant. Wanneer een app zich registreert bij het Spring Cloud Service Registry, kan Spring Cloud Gateway de app detecteren, zodat deze routeringsregels kan gebruiken om verkeer door te sturen naar de juiste doel-app.

Als gevolg hiervan is uw Spring Cloud Gateway-app uw Spring Cloud Gateway-app waaraan een eindpunt moet zijn toegewezen in Azure Spring Apps. Dit eindpunt maakt het bereikbaar vanaf de buitenkant. U moet geen eindpunt toewijzen aan andere apps. Anders kunnen de apps rechtstreeks worden bereikt in plaats van via Spring Cloud Gateway, waardoor de omgekeerde proxy op zijn beurt kan worden omzeild.

Een eenvoudige manier om alle geregistreerde apps beschikbaar te maken via Spring Cloud Gateway is door de discoveryClient routedefinitiezoeker als volgt te gebruiken:

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

U kunt ook bepaalde apps selectief beschikbaar maken via Spring Cloud Gateway door app-specifieke routes te definiëren:

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

Met zowel de detectiezoekerbenadering als expliciete routedefinities kunt u routepredicaten gebruiken om ongeldige aanvragen te weigeren. In dit geval gebruiken we die functionaliteit om aanvragen te blokkeren die niet afkomstig zijn van de verwachte omgekeerde proxy die zich voor Azure Spring Apps bevindt.

Toegang beperken met de X-Forwarded-For HTTP-header

Wanneer u een app in Azure Spring Apps implementeert, maakt de HTTP-client of omgekeerde proxy niet rechtstreeks verbinding met de app. Netwerkverkeer gaat eerst via een interne ingangscontroller.

Vanwege de extra service is het IP-adres van de directe netwerkclient altijd een intern Azure Spring Apps-onderdeel. Het IP-adres is nooit de logische client, zoals de omgekeerde proxy die u verwacht uw app aan te roepen. U kunt het IP-adres van de client niet gebruiken voor toegangsbeperkingen. U kunt ook het ingebouwde RemoteAddr routepredicaat van Spring Cloud Gateway niet gebruiken voor het filteren van aanvragen, omdat het standaard het IP-adres van de client gebruikt.

Gelukkig voegt Azure Spring Apps het IP-adres van de logische client altijd toe aan de X-Forwarded-For HTTP-header van de aanvraag in uw app. De laatste (meest rechtse) waarde van de X-Forwarded-For header bevat altijd het IP-adres van de logische client.

Als u aanvragen wilt filteren op basis van de X-Forwarded-For header, kunt u het ingebouwde XForwarded Remote Addr routepredicaat gebruiken. Met dit predicaat kunt u een lijst met de IP-adressen of IP-bereiken van uw omgekeerde proxy configureren die als meest rechtse waarde zijn toegestaan.

Uw app configureren om de juiste hostnaam en aanvraag-URL te zien

Wanneer u Spring Cloud Gateway gebruikt, is er een belangrijke factor om rekening mee te houden. Spring Cloud Gateway stelt de HTTP-header Host in de uitgaande aanvraag in op het interne IP-adres van uw app-exemplaar, zoals Host: 10.2.1.15:1025. De hostnaam van de aanvraag die door uw toepassingscode wordt weergegeven, is niet langer de oorspronkelijke hostnaam van de aanvraag die de browser heeft verzonden, zoals contoso.com. In sommige gevallen kan dit resultaat leiden tot problemen zoals verbroken cookies of omleidings-URL's die niet goed werken. Zie Behoud van hostnamen voor meer informatie over deze typen problemen en het configureren van een omgekeerde proxyservice, zoals Application Gateway of Azure Front Door.

Spring Cloud Gateway biedt de oorspronkelijke hostnaam in de Forwarded header. Er worden ook andere headers ingesteld, zoals X-Forwarded-Port, X-Forwarded-Protoen X-Forwarded-Prefix zodat uw toepassing deze kan gebruiken om de oorspronkelijke aanvraag-URL te reconstrueren. In Spring Framework-toepassingen kunt u deze configuratie automatisch bereiken door de server.forward-headers-strategy instelling FRAMEWORK in te stellen op uw toepassingseigenschappen. (Stel deze waarde niet in op NATIVE. Anders worden andere headers gebruikt die niet rekening houden met de vereiste X-Forwarded-Prefix header.) Zie Uitvoeren achter een front-endproxyserver voor meer informatie. Met deze configuratie neemt de methode HttpServletRequest.getRequestURL al deze headers in aanmerking en retourneert de exacte aanvraag-URL zoals verzonden door de browser.

Scenario 3: Application Gateway gebruiken met Spring Cloud Gateway

In scenario 3 wordt beschreven hoe u Application Gateway gebruikt als de omgekeerde proxy voor openbaar bereikbare apps via een Spring Cloud Gateway-eindpunt.

In het volgende diagram ziet u de architectuur voor Scenario 3:

Een Visio-bestand van deze architectuur downloaden.

Wanneer Application Gateway zich voor uw Azure Spring Apps-exemplaar bevindt, gebruikt u het toegewezen eindpunt van de Spring Cloud Gateway-app als back-endpool. Een voorbeeldeindpunt is myspringcloudservice-mygateway.azuremicroservices.io. Omdat Azure Spring Apps buiten een virtueel netwerk wordt geïmplementeerd, wordt deze URL omgezet in een openbaar IP-adres. Wanneer de back-endpool een openbaar eindpunt is, gebruikt Application Gateway het openbare IP-adres van de front-end om de back-endservice te bereiken.

Als u alleen aanvragen van uw Application Gateway-exemplaar wilt toestaan om Spring Cloud Gateway te bereiken, kunt u het XForwarded Remote Addr routepredicaat configureren. Configureer het predicaat zodat alleen aanvragen van het toegewezen openbare IP-adres van uw Toepassingsgateway worden toegestaan, zoals wordt weergegeven in het volgende voorbeeld:

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

Scenario 4: Azure Front Door gebruiken met Spring Cloud Gateway

In scenario 4 wordt beschreven hoe u Azure Front Door gebruikt als de omgekeerde proxy voor openbaar bereikbare apps via een Spring Cloud Gateway-eindpunt.

In het volgende diagram ziet u de architectuur voor Scenario 4:

Een Visio-bestand van deze architectuur downloaden.

Net als bij Scenario 3 gebruikt deze configuratie de openbare URL van de Spring Cloud Gateway-app als de back-endpool of origin in Azure Front Door. Een voorbeeldeindpunt is https://myspringcloudservice-mygateway.azuremicroservices.io.

Omdat Azure Front Door een wereldwijde service is met veel edge-locaties, gebruikt het veel IP-adressen om te communiceren met de back-endpool. In de Documentatie van Azure Front Door wordt beschreven hoe u de toegang tot een back-end kunt vergrendelen om alleen Verkeer van Azure Front Door toe te staan. In dit scenario bepaalt u echter niet het Azure-netwerk waarin uw apps worden geïmplementeerd. Helaas kunt u de AzureFrontDoor.Backend servicetag niet gebruiken om een volledige lijst met uitgaande Azure Front Door-IP-adressen op te halen die gegarandeerd actueel zijn. In plaats daarvan moet u Azure IP-bereiken en servicetags downloaden, de AzureFrontDoor.Backend sectie zoeken en alle IP-bereiken uit de addressPrefixes matrix kopiëren naar de configuratie van het XForwarded Remote Addr routepredicaat.

Omdat de IP-adresbereiken van Azure Front Door worden gedeeld met andere organisaties, moet u er ook voor zorgen dat u alleen toegang tot uw specifieke Azure Front Door-exemplaar vergrendelt op basis van de X-Azure-FDID HTTP-header die uw unieke Front Door IDheader bevat. U kunt de toegang beperken met behulp van het Header routepredicaat, dat een aanvraag weigert, tenzij een opgegeven HTTP-header een bepaalde waarde heeft.

In dit scenario kan de predicaatconfiguratie van uw Spring Cloud Gateway-route er als volgt uitzien:

(...)
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", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

Bijdragers

Microsoft onderhoudt deze inhoud. De volgende inzender heeft de oorspronkelijke inhoud ontwikkeld.

Hoofdauteur:

• Jelle Druyts | Principal Customer Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Referentiearchitectuur voor Azure Spring Apps
• Verantwoordelijkheden van de klant voor het uitvoeren van Azure Spring Apps in Azure Virtual Networks

Verwante resources

• Behoud van hostnaam
• Opties voor taakverdeling
• Architectuurstijl voor microservices