Esporre Azure Spring Apps tramite un proxy inverso

Quando si ospitano le app o i microservizi in Azure Spring Apps, non è sempre necessario pubblicarli direttamente in Internet. È invece consigliabile esporli tramite un proxy inverso. Questo approccio consente di posizionare un servizio davanti alle app. Il servizio può definire funzionalità trasversali come le funzionalità web application firewall (WAF) per proteggere le app, il bilanciamento del carico, il routing, il filtro delle richieste e la limitazione della velocità.

Quando si distribuisce un servizio proxy inverso comune, ad esempio app Azure lication Gateway o Frontdoor di Azure davanti ad Azure Spring Apps, è necessario assicurarsi che le app possano essere raggiunte solo tramite il proxy inverso. Questa protezione consente di impedire agli utenti malintenzionati di tentare di ignorare il WAF o aggirare i limiti di limitazione.

Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Questo articolo descrive come applicare restrizioni di accesso in modo che le applicazioni ospitate in Azure Spring Apps siano accessibili solo tramite un servizio proxy inverso. Il modo consigliato per applicare queste restrizioni dipende dalla modalità di distribuzione dell'istanza di Azure Spring Apps e del proxy inverso usato. Sono diversi punti da considerare a seconda che si distribuisca all'interno o all'esterno di una rete virtuale. Questo articolo fornisce informazioni su quattro scenari.

• Distribuire Azure Spring Apps all'interno di una rete virtuale e accedere alle app privatamente dall'interno della rete.

  • Si ha il controllo sulla rete virtuale in cui vengono eseguite le app. Usare funzionalità di rete native di Azure come i gruppi di sicurezza di rete (NSG) per bloccare l'accesso per consentire solo il proxy inverso.

  • È possibile esporre le app pubblicamente a Internet usando app Azure lication Gateway e quindi applicare le restrizioni di accesso appropriate per bloccarla. Questo approccio è descritto nello scenario 1 più avanti in questo articolo.

  • Non è possibile usare Frontdoor di Azure direttamente perché non riesce a raggiungere l'istanza di Azure Spring Apps nella rete virtuale privata. Frontdoor di Azure può connettersi ai back-end solo tramite un indirizzo IP pubblico o tramite servizi che usano un endpoint privato. Quando si ha una distribuzione in più aree di Azure Spring Apps e si richiede il bilanciamento del carico globale, è comunque possibile esporre le istanze di Azure Spring Apps tramite gateway applicazione. Per ottenere questo scenario, è possibile posizionare Frontdoor di Azure davanti a gateway applicazione. Questo approccio è descritto nello scenario 2 più avanti in questo articolo.

• Distribuire App Azure Spring all'esterno di una rete virtuale e pubblicare le app direttamente in Internet, se le si assegna un endpoint.

  • Non si controlla la rete e non è possibile usare gruppi di sicurezza di rete per limitare l'accesso. Per consentire l'accesso alle app solo il proxy inverso richiede un approccio all'interno di Azure Spring Apps stesso.

  • Poiché le app sono raggiungibili pubblicamente, è possibile usare gateway applicazione o Frontdoor di Azure come proxy inverso. L'approccio gateway applicazione è descritto nello scenario 3 più avanti in questo articolo. L'approccio frontdoor di Azure è descritto nello scenario 4 più avanti in questo articolo.

  • È possibile usare una combinazione di entrambi gli approcci, in base alle esigenze. Se si usano sia gateway applicazione che frontdoor di Azure, usare le stesse restrizioni di accesso tra i due proxy inversi usati nello scenario 2.

Confronto tra scenari

La tabella seguente fornisce un breve confronto dei quattro scenari di configurazione del proxy inverso per Azure Spring Apps. Per informazioni dettagliate su ogni scenario, vedere la sezione appropriata di questo articolo.

Distribuzione all'interno della rete virtuale

Quando Azure Spring Apps viene distribuito in una rete virtuale, usa due subnet:

• Subnet del runtime del servizio che contiene le risorse di rete pertinenti
• Una subnet di app che ospita il codice

Poiché la subnet del runtime del servizio contiene il servizio di bilanciamento del carico per la connessione alle app, è possibile definire un gruppo di sicurezza di rete in questa subnet del runtime del servizio per consentire il traffico solo dal proxy inverso. Quando si blocca tutto l'altro traffico, nessuno nella rete virtuale può accedere alle app senza passare attraverso il proxy inverso.

Ogni app che si vuole esporre tramite il proxy inverso deve avere un endpoint assegnato in modo che il proxy inverso possa raggiungere l'app nella rete virtuale. Per ogni app, è anche necessario eseguire il mapping dei domini personalizzati usati per evitare di eseguire l'override dell'intestazione HTTP Host nel proxy inverso e mantenere intatto il nome host originale. Questo metodo evita problemi come cookie interrotti o URL di reindirizzamento che non funzionano correttamente. Per altre informazioni, vedere Conservazione dei nomi host.

Scenario 1: Usare gateway applicazione come proxy inverso

Lo scenario 1 descrive come esporre le app pubblicamente a Internet usando gateway applicazione e quindi applicare le restrizioni di accesso appropriate per bloccarlo.

Il diagramma seguente illustra l'architettura per lo scenario 1:

Scaricare un file di Visio di questa architettura.

Quando gateway applicazione si trova davanti all'istanza di Azure Spring Apps, si usa l'endpoint assegnato dell'app Spring Cloud Gateway come pool back-end. Un endpoint di esempio è myspringcloudservice-myapp.private.azuremicroservices.io. L'endpoint viene risolto in un indirizzo IP privato nella subnet del runtime del servizio. Pertanto, per limitare l'accesso, è possibile inserire un gruppo di sicurezza di rete nella subnet del runtime del servizio con le regole di sicurezza in ingresso seguenti (assegnando alla regola Nega la priorità più bassa):

La configurazione dello scenario 1 garantisce che la subnet del runtime del servizio consenta il traffico solo dalle origini seguenti:

• Subnet dedicata gateway applicazione
• La subnet delle app (comunicazione bidirezionale tra le due subnet di Azure Spring Apps è necessaria).
• Servizio di bilanciamento del carico di Azure (che è un requisito generale della piattaforma Azure)

Tutto l'altro traffico viene bloccato.

Scenario 2: usare frontdoor di Azure e gateway applicazione come proxy inverso

Come indicato in precedenza, non è possibile posizionare Frontdoor di Azure direttamente davanti ad Azure Spring Apps perché non riesce a raggiungere la rete virtuale privata. Frontdoor di Azure Standard o Premium può connettersi a endpoint privati in una rete virtuale, ma Azure Spring Apps attualmente non offre supporto per endpoint privati. Se si vuole comunque usare Frontdoor di Azure, ad esempio per richiedere il bilanciamento del carico globale in più istanze di App Spring di Azure in aree di Azure diverse, è comunque possibile esporre le app tramite gateway applicazione. Per ottenere questo scenario, è possibile posizionare Frontdoor di Azure davanti a gateway applicazione.

Il diagramma seguente illustra l'architettura per lo scenario 2:

Scaricare un file di Visio di questa architettura.

La configurazione dello scenario 2 implementa le restrizioni di accesso tra gateway applicazione e Azure Spring Apps nello stesso modo dello scenario 1. Si inserisce un gruppo di sicurezza di rete nella subnet del runtime del servizio con le regole appropriate.

Nello scenario 2 è anche necessario assicurarsi che gateway applicazione accetti il traffico proveniente solo dall'istanza di Frontdoor di Azure. La documentazione di Frontdoor di Azure illustra come bloccare l'accesso a un back-end per consentire solo il traffico frontdoor di Azure. Quando il back-end è gateway applicazione, è possibile implementare questa restrizione come indicato di seguito:

• Nella subnet gateway applicazione creare un gruppo di sicurezza di rete per consentire solo il traffico con tag del AzureFrontDoor.Backend servizio (ad eccezione di Frontdoor di Azure può raggiungere gateway applicazione). Assicurarsi di includere anche altri tag di servizio necessari, come descritto in Restrizioni del gruppo di sicurezza di rete per gateway applicazione.
• Creare una regola WAF personalizzata in gateway applicazione per verificare che l'intestazione HTTP sia impostata sull'ID X-Azure-FDIDistanza di Frontdoor di Azure specifico. Questo metodo garantisce che nessun'altra istanza di Frontdoor di Azure dell'organizzazione che usi gli stessi intervalli IP possa raggiungere l'istanza di gateway applicazione.

Distribuzione all'esterno della rete virtuale

Quando si distribuiscono App Spring di Azure all'esterno di una rete virtuale, non è possibile usare le funzionalità di rete native di Azure perché non si controlla la rete. È invece necessario applicare le restrizioni di accesso necessarie alle app stesse per consentire il traffico solo dal proxy inverso. Se si hanno molte app, questo approccio può aggiungere complessità e c'è il rischio che non tutte le app possano essere configurate in modo appropriato.

Usare Spring Cloud Gateway per esporre e proteggere le app

Per rimuovere la responsabilità del controllo di accesso dagli sviluppatori di singole applicazioni, è possibile applicare restrizioni trasversali usando Spring Cloud Gateway. Spring Cloud Gateway è un progetto Spring comunemente usato che è possibile distribuire in App Spring di Azure esattamente come qualsiasi altra app. Usando Spring Cloud Gateway, è possibile mantenere private le proprie applicazioni all'interno dell'istanza di Azure Spring Apps e assicurarsi che sia accessibile solo tramite l'app Spring Cloud Gateway condivisa. È quindi possibile configurare questa app con le restrizioni di accesso necessarie usando i predicati di route, che sono una funzionalità predefinita di Spring Cloud Gateway. I predicati di route possono usare attributi diversi della richiesta HTTP in ingresso per determinare se indirizzare la richiesta all'applicazione back-end o rifiutarla. Il predicato può usare attributi come l'indirizzo IP del client, il metodo di richiesta o il percorso, le intestazioni HTTP e così via.

Questo modello viene comunemente usato. Ai fini di questo articolo, si presuppone che l'utente esponga le applicazioni tramite Spring Cloud Gateway. Si prevede di usare i predicati di route per configurare le restrizioni di accesso necessarie per garantire che siano consentite solo le richieste dal proxy inverso. Anche se non si usa Spring Cloud Gateway, si applicano gli stessi principi generali. Tuttavia, è necessario creare funzionalità di filtro delle richieste personalizzate nelle app in base alla stessa X-Forwarded-For intestazione HTTP descritta più avanti in questo articolo.

Descrivere il funzionamento di Spring Cloud Gateway non rientra nell'ambito di questo articolo. Si tratta di un servizio altamente flessibile che è possibile personalizzare tramite codice o configurazione. Per semplificare le operazioni, questo articolo descrive solo un approccio puramente basato sulla configurazione che non richiede modifiche al codice. È possibile implementare questo approccio includendo il application.properties file tradizionale o application.yml nell'app Spring Cloud Gateway distribuita. È anche possibile implementare l'approccio usando un server di configurazione in Azure Spring Apps che esterna il file di configurazione in un repository Git. Negli esempi seguenti viene implementato l'approccio con la application.yml sintassi YAML, ma funziona anche la sintassi equivalente application.properties .

Instradare le richieste alle applicazioni

Per impostazione predefinita, quando l'app in Azure Spring Apps non ha un endpoint assegnato o un dominio personalizzato configurato per esso, non è raggiungibile dall'esterno. Quando un'app si registra con Spring Cloud Service Registry, Spring Cloud Gateway può individuare l'app in modo da poter usare le regole di routing per inoltrare il traffico all'app di destinazione corretta.

Di conseguenza, l'unica app che deve avere un endpoint assegnato in Azure Spring Apps è l'app Spring Cloud Gateway. Questo endpoint lo rende raggiungibile dall'esterno. Non è consigliabile assegnare un endpoint ad altre app. In caso contrario, le app possono essere raggiunte direttamente anziché tramite Spring Cloud Gateway, che a sua volta consente di ignorare il proxy inverso.

Un modo semplice per esporre tutte le app registrate tramite Spring Cloud Gateway consiste nell'usare il localizzatore di definizioni di route DiscoveryClient come indicato di seguito:

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

In alternativa, è possibile esporre in modo selettivo determinate app tramite Spring Cloud Gateway definendo route specifiche dell'app:

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

Con l'approccio del localizzatore di individuazione e le definizioni di route esplicite, è possibile usare i predicati di route per rifiutare le richieste non valide. In questo caso, si usa questa funzionalità per bloccare le richieste che non provengono dal proxy inverso previsto che si trova davanti ad Azure Spring Apps.

Limitare l'accesso con l'intestazione X-Forwarded-For HTTP

Quando si distribuisce un'app in Azure Spring Apps, il client HTTP o il proxy inverso non si connette direttamente all'app. Il traffico di rete passa prima attraverso un controller di ingresso interno.

A causa del servizio aggiuntivo, l'indirizzo IP del client di rete diretta è sempre un componente interno di Azure Spring Apps. L'indirizzo IP non è mai il client logico come il proxy inverso che si prevede di chiamare l'app. Non è possibile usare l'indirizzo IP client per le restrizioni di accesso. Non è anche possibile usare il predicato di route predefinito RemoteAddr di Spring Cloud Gateway per il filtro delle richieste perché usa l'indirizzo IP client per impostazione predefinita.

Fortunatamente, Azure Spring Apps aggiunge sempre l'indirizzo IP del client logico all'intestazione X-Forwarded-For HTTP nella richiesta nell'app. L'ultimo valore (più a destra) dell'intestazione X-Forwarded-For contiene sempre l'indirizzo IP del client logico.

Per filtrare le richieste in base all'intestazioneX-Forwarded-For, è possibile usare il predicato di XForwarded Remote Addr route predefinito. Questo predicato consente di configurare un elenco degli indirizzi IP o degli intervalli IP del proxy inverso consentiti come valore più appropriato.

Configurare l'app per visualizzare il nome host e l'URL della richiesta corretti

Quando si usa Spring Cloud Gateway, è necessario considerare un fattore importante. Spring Cloud Gateway imposta l'intestazione HTTP Host nella richiesta in uscita sull'indirizzo IP interno dell'istanza dell'app, ad esempio Host: 10.2.1.15:1025. Il nome host della richiesta visualizzato dal codice dell'applicazione non è più il nome host originale della richiesta inviata dal browser, ad esempio contoso.com. In alcuni casi, questo risultato può causare problemi come cookie interrotti o URL di reindirizzamento che non funzionano correttamente. Per altre informazioni su questi tipi di problemi e su come configurare un servizio proxy inverso, ad esempio gateway applicazione o Frontdoor di Azure per evitarli, vedere Conservazione dei nomi host.

Spring Cloud Gateway fornisce il nome host originale nell'intestazioneForwarded. Imposta anche altre intestazioni come X-Forwarded-Port, X-Forwarded-Protoe X-Forwarded-Prefix in modo che l'applicazione possa usarle per ricostruire l'URL della richiesta originale. Nelle applicazioni Spring Framework è possibile ottenere questa configurazione automaticamente impostando l'impostazione server.forward-headers-strategy su FRAMEWORK nelle proprietà dell'applicazione. Non impostare questo valore su NATIVE. In caso contrario, vengono usate altre intestazioni che non prendono in considerazione l'intestazione richiesta X-Forwarded-Prefix . Per altre informazioni, vedere Esecuzione dietro un server proxy front-end. Con questa configurazione, il metodo HttpServletRequest.getRequestURL prende in considerazione tutte queste intestazioni e restituisce l'URL esatto della richiesta inviato dal browser.

Scenario 3: Usare gateway applicazione con Spring Cloud Gateway

Lo scenario 3 descrive come usare gateway applicazione come proxy inverso per le app raggiungibili pubblicamente tramite un endpoint Spring Cloud Gateway.

Il diagramma seguente illustra l'architettura per lo scenario 3:

Scaricare un file di Visio di questa architettura.

Quando gateway applicazione si trova davanti all'istanza di Azure Spring Apps, si usa l'endpoint assegnato dell'app Spring Cloud Gateway come pool back-end. Un endpoint di esempio è myspringcloudservice-mygateway.azuremicroservices.io. Poiché Azure Spring Apps viene distribuito all'esterno di una rete virtuale, questo URL viene risolto in un indirizzo IP pubblico. Quando il pool back-end è un endpoint pubblico, gateway applicazione usa l'indirizzo IP pubblico front-end per raggiungere il servizio back-end.

Per consentire solo alle richieste provenienti dall'istanza di gateway applicazione di raggiungere Spring Cloud Gateway, è possibile configurare il predicato di XForwarded Remote Addr route. Configurare il predicato per consentire solo le richieste dall'indirizzo IP pubblico dedicato del gateway applicazione, come illustrato nell'esempio seguente:

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

Scenario 4: Usare Frontdoor di Azure con Spring Cloud Gateway

Lo scenario 4 descrive come usare Frontdoor di Azure come proxy inverso per le app raggiungibili pubblicamente tramite un endpoint spring cloud gateway.

Il diagramma seguente illustra l'architettura per lo scenario 4:

Scaricare un file di Visio di questa architettura.

Analogamente allo scenario 3, questa configurazione usa l'URL pubblico dell'app Spring Cloud Gateway come pool back-end o origine in Frontdoor di Azure. Un endpoint di esempio è https://myspringcloudservice-mygateway.azuremicroservices.io.

Poiché Frontdoor di Azure è un servizio globale con molte posizioni perimetrali, usa molti indirizzi IP per comunicare con il pool back-end. La documentazione di Frontdoor di Azure descrive come bloccare l'accesso a un back-end per consentire solo il traffico di Frontdoor di Azure. In questo scenario, tuttavia, non si controlla la rete di Azure in cui vengono distribuite le app. Sfortunatamente, non è possibile usare il tag del AzureFrontDoor.Backend servizio per ottenere un elenco completo di indirizzi IP frontdoor di Azure in uscita che è garantito essere aggiornato. È invece necessario scaricare gli intervalli IP e i tag di servizio di Azure, trovare la AzureFrontDoor.Backend sezione e copiare tutti gli intervalli IP dalla addressPrefixes matrice alla configurazione del predicato di XForwarded Remote Addr route.

Poiché gli intervalli IP frontdoor di Azure sono condivisi con altre organizzazioni, è anche necessario assicurarsi di bloccare l'accesso solo all'istanza specifica di Frontdoor di Azure, in base all'intestazione HTTP che contiene l'univoco X-Azure-FDID Front Door ID. È possibile limitare l'accesso usando il Header predicato di route, che rifiuta una richiesta a meno che un'intestazione HTTP specificata non abbia un determinato valore.

In questo scenario, la configurazione del predicato di route di Spring Cloud Gateway potrebbe essere simile all'esempio seguente:

(...)
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"

Collaboratori

Microsoft gestisce questo contenuto. Il collaboratore seguente ha sviluppato il contenuto originale.

Autore principale:

• Jelle Druyts | Principal Customer Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Architettura di riferimento di Azure Spring Apps
• Responsabilità dei clienti per l'esecuzione di App Spring di Azure in Azure Rete virtuale

Risorse correlate

• Conservazione dei nomi host
• Opzioni di bilanciamento del carico
• Stile dell'architettura dei microservizi