Preparare la distribuzione del carico di lavoro dell'applicazione Web Amazon Web Services (AWS) in Azure

Questo articolo fornisce una guida completa su come distribuire un'infrastruttura affidabile e pronta per la produzione per facilitare l'hosting, la protezione, il ridimensionamento e il monitoraggio di un'applicazione Web nella piattaforma Azure.

Distribuzione di Yelb su AWS

L'applicazione Web di esempio Yelb in AWS viene distribuita usando Bash, l'interfaccia della riga di comando di AWS, eksctl, kubectl e Helm. L'esempio complementare contiene script Bash e manifesti YAML che è possibile usare per automatizzare la distribuzione dell'applicazione Yelb in AWS Elastic Kubernetes Service (EKS). Questa soluzione illustra come implementare un web application firewall usando AWS WAF per proteggere un'applicazione Web in esecuzione in Amazon Elastic Kubernetes Service (EKS). È possibile utilizzare gli script Bash per creare un cluster EKS e distribuire l'applicazione Yelb. L'applicazione Web Yelb viene esposta alla rete Internet pubblica usando un'applicazione Amazon Load Balancer (ALB) e protetta tramite AWS WAF Web access control list (ACL Web). Per istruzioni dettagliate, vedere Porting a Web Application from AWS Elastic Kubernetes Service (EKS) to Servizio Azure Kubernetes (AKS) (Conversione di un'applicazione Web dal servizio Elastic Kubernetes di AWS) a Servizio Azure Kubernetes (AKS).

Screenshot dell'interfaccia del servizio Yelb.

Distribuzione di Yelb in Azure

Nelle sezioni seguenti viene illustrato come distribuire l'applicazione Web di esempio Yelb in un cluster Servizio Azure Kubernetes (AKS) ed esporla tramite un controller di ingresso come il controller di ingresso NGINX. Il servizio del controller di ingresso è accessibile tramite un bilanciatore del carico interno (o privato), che bilancia il traffico all'interno della rete virtuale in cui è ospitato il cluster AKS. In uno scenario ibrido, è possibile accedere al front-end del servizio di bilanciamento del carico da una rete locale. Per altre informazioni sul bilanciamento del carico interno, vedere Usare un servizio di bilanciamento del carico interno con Servizio Azure Kubernetes (AKS).

L'esempio complementare supporta l'installazione di un controller di ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione o un controller di ingresso NGINX non gestito usando il grafico Helm. Il componente aggiuntivo di routing dell'applicazione con il controller di ingresso NGINX offre le funzionalità seguenti:

Per altre configurazioni,

Per migliorare la sicurezza, l'applicazione Yelb è protetta da una risorsa gateway applicazione di Azure. Questa risorsa viene distribuita in una subnet dedicata all'interno della stessa rete virtuale del cluster AKS o in una rete virtuale connessa tramite peering. Il Web application firewall di Azure (WAF) protegge l'accesso all'applicazione Web ospitata in Servizio Azure Kubernetes (AKS) ed esposta tramite il gateway applicazione di Azure contro exploit e vulnerabilità comuni.

Prerequisiti

Architecture

Questo esempio fornisce una raccolta di modelli Bicep, script Bash e manifest YAML per creare un cluster AKS, distribuire l'applicazione Yelb, esporre il servizio dell'interfaccia utente usando il controller Ingress NGINX e proteggerla con gateway applicazione di Azure e Web application firewall di Azure (WAF).

Questo esempio include anche due file di parametri Bicep separati e due set di script Bash e manifesti YAML, ognuno orientato alla distribuzione di due diverse opzioni di soluzione. Per altre informazioni sulle Bicep, vedere Che cos'è Bicep?

Terminazione TLS in Application Gateway e invocazione di Yelb tramite HTTP

In questa soluzione, il Web application firewall di Azure (WAF) garantisce la sicurezza del sistema bloccando gli attacchi dannosi. Il gateway applicazione di Azure riceve le richieste in ingresso dalle applicazioni client, esegue la terminazione TLS e inoltra le richieste al servizio yelb-ui ospitato in Azure Kubernetes Service (AKS). Questa comunicazione viene ottenuta tramite il servizio di bilanciamento del carico interno e il controller di ingresso NGINX usando il protocollo di trasporto HTTP. Il diagramma seguente illustra l'architettura:

Diagramma della soluzione basata su Application Gateway WAFv2 e sul controller ingress NGINX tramite HTTP.

Il flusso del messaggio è il seguente:

Diagramma del flusso dei messaggi della soluzione basata su Application Gateway WAFv2 e sul controller Ingress NGINX tramite HTTP.

  1. Il gateway applicazione di Azure gestisce la terminazione TLS e invia le chiamate in ingresso al servizio yelb-ui ospitato in AKS tramite HTTP.
  2. Il Listener del Gateway applicazione utilizza un certificato SSL ottenuto da Azure Key Vault per garantire una comunicazione sicura.
  3. I criteri WAF Azure associati al listener applicano regole OWASP e regole personalizzate alle richieste in ingresso, impedendo in modo efficace molti tipi di attacchi dannosi.
  4. Le impostazioni HTTP di back-end di Application Gateway invocano l'applicazione Yelb tramite HTTP sulla porta 80.
  5. Il pool back-end di Application Gateway e il probe di integrità raggiungono il controller di ingresso NGINX tramite il bilanciatore del carico interno di AKS usando il protocollo HTTP per la gestione del traffico.
  6. Il controller di ingresso NGINX usa il servizio di bilanciamento del carico interno del servizio Azure Kubernetes per garantire la comunicazione sicura all'interno del cluster.
  7. Un oggetto in ingresso Kubernetes usa il controller di ingresso NGINX per esporre l'applicazione tramite HTTP tramite il servizio di bilanciamento del carico interno.
  8. Il servizio yelb-ui con il tipo ClusterIP limita la relativa chiamata all'interno del cluster o tramite il controller Ingress NGINX.

Implementazione di TLS end-to-end tramite gateway applicazione di Azure

TLS termination

gateway applicazione di Azure supporta la terminazione TLS a livello di gateway, il che significa che il traffico viene decrittografato nel gateway prima di essere inviato ai server back-end. Per configurare la terminazione TLS, è necessario aggiungere un certificato TLS/SSL al listener. Il certificato deve essere in formato PFX (Personal Information Exchange), che contiene sia le chiavi private che pubbliche. È possibile importare il certificato da Azure Key Vault al gateway applicazione. Per altre informazioni, vedere Terminazione TLS con certificati di Key Vault.

Modello di sicurezza Zero Trust

Se si adotta un modello di sicurezza Zero Trust, è consigliabile impedire la comunicazione non crittografata tra un proxy del servizio, ad esempio gateway applicazione di Azure e i server back-end. Con il modello di sicurezza Zero Trust, l'attendibilità non viene concessa automaticamente a nessun utente o dispositivo che tenta di accedere alle risorse all'interno di una rete. Richiede invece la verifica continua dell'identità e dell'autorizzazione per ogni richiesta, indipendentemente dal percorso o dalla rete dell'utente. In questo scenario, l'implementazione del modello di sicurezza Zero Trust comporta l'uso del gateway applicazione di Azure come proxy del servizio, che funge da front-end per le richieste in ingresso. Queste richieste passano quindi al controller di ingresso NGINX in Servizio Azure Kubernetes (AKS) in un formato crittografato.

TLS end-to-end con Application Gateway

È possibile implementare un approccio Zero Trust configurando gateway applicazione di Azure per la crittografia TLS end-to-end con i server back-end. La crittografia TLS end-to-end consente di trasmettere in modo sicuro i dati sensibili al back-end sfruttando al tempo stesso le funzionalità di bilanciamento del carico di livello 7 offerte da Application Gateway, tra cui l'affinità di sessione basata su cookie, il routing basato su URL, il routing basato sui siti e la possibilità di riscrivere o inserire intestazioni X-Forwarded-*.

Quando Application Gateway è configurato in modalità di comunicazione TLS end-to-end, termina le sessioni TLS sul gateway e decritta il traffico utente. Applica quindi le regole configurate per selezionare l'istanza appropriata del pool back-end verso cui instradare il traffico. Successivamente, il gateway applicazione avvia una nuova connessione TLS al server back-end e crittografa i dati usando il certificato di chiave pubblica del server back-end prima di trasmettere la richiesta al back-end. La risposta del server Web segue lo stesso processo prima di raggiungere l'utente finale. Per abilitare TLS end-to-end, è necessario impostare l'impostazione del protocollo nell'impostazione HTTP back-end su HTTPS e applicarla a un pool back-end. Questo approccio garantisce che la comunicazione con i server back-end sia protetta e conforme ai requisiti.

Per altre informazioni, vedere Crittografia TLS end-to-end di Application Gateway e Procedure consigliate per la protezione di Application Gateway.

In questa soluzione, il Web application firewall di Azure (WAF) garantisce la sicurezza del sistema bloccando gli attacchi dannosi. Il gateway applicazione di Azure gestisce le chiamate in ingresso dalle applicazioni client, esegue la terminazione TLS e implementa TLS end-to-end richiamando il servizio ospitato dal yelb-ui servizio AKS sottostante usando il protocollo di trasporto HTTPS tramite il servizio di bilanciamento del carico interno e il controller di ingresso NGINX. Il diagramma seguente illustra l'architettura:

Diagramma della soluzione basata su Application Gateway WAFv2 e sul controller di ingresso NGINX tramite HTTPS.

Il flusso del messaggio è il seguente:

  1. Il gateway applicazione di Azure gestisce la terminazione TLS e comunica con l'applicazione back-end tramite HTTPS.
  2. Il listener del gateway applicazione usa un certificato SSL ottenuto da Azure Key Vault.
  3. Il criterio WAF di Azure associato al Listener applica le regole OWASP e le regole personalizzate alle richieste in ingresso per bloccare attacchi malevoli.
  4. Le impostazioni HTTP del back-end di Gateway applicazione sono configurate per richiamare il servizio yelb-ui ospitato in AKS tramite HTTPS sulla porta 443.
  5. Il pool di backend del gateway applicativo e la probe di integrità raggiungono il controller Ingress NGINX tramite il bilanciatore del carico interno di AKS usando HTTPS.
  6. Il controller Ingress NGINX è distribuito per usare il bilanciatore del carico interno di AKS.
  7. Il cluster SAKS è configurato con il componente aggiuntivo provider di Azure Key Vault per Secrets Store CSI Driver per recuperare segreti, certificati e chiavi da Azure Key Vault tramite un volume CSI.
  8. Un SecretProviderClass viene utilizzato per recuperare da Key Vault il certificato usato da Application Gateway.
  9. Un oggetto ingress di Kubernetes usa il controller ingress NGINX per esporre l'applicazione tramite HTTPS attraverso il bilanciatore del carico interno di AKS.
  10. Il yelb-ui servizio ha un ClusterIP tipo, che ne limita la chiamata all'interno del cluster o tramite il controller di ingresso NGINX.

Per garantire la sicurezza e la stabilità del sistema, considerare le raccomandazioni seguenti:

  • Aggiornare regolarmente i criteri WAF Azure con le regole più recenti per garantire una sicurezza ottimale.
  • Implementare meccanismi di monitoraggio e registrazione per tenere traccia e analizzare le richieste in ingresso e i potenziali attacchi.
  • Eseguire regolarmente manutenzione e aggiornamenti del cluster del servizio Azure Kubernetes, del controller di ingresso NGINX e del gateway applicazione per risolvere eventuali vulnerabilità di sicurezza e mantenere un'infrastruttura sicura.
  • Implementare meccanismi di monitoraggio e registrazione per tenere traccia e analizzare le richieste in ingresso e i potenziali attacchi.
  • Eseguire regolarmente manutenzione e aggiornamenti del cluster del servizio Azure Kubernetes, del controller di ingresso NGINX e del gateway applicazione per risolvere eventuali vulnerabilità di sicurezza e mantenere un'infrastruttura sicura.

Hostname

Il listener di Application Gateway e Kubernetes ingress sono configurati per usare lo stesso hostname. È importante usare lo stesso nome host per un proxy di servizio e un'applicazione Web back-end per i motivi seguenti:

  • Conservazione dello stato della sessione: quando si usa un nome host diverso per il proxy e l'applicazione back-end, lo stato della sessione può andare perso. Ciò significa che le sessioni utente potrebbero non essere persistenti correttamente, causando una scarsa esperienza utente e una potenziale perdita di dati.
  • Errore di autenticazione: se il nome host è diverso tra il proxy e l'applicazione back-end, i meccanismi di autenticazione potrebbero non riuscire. Questo approccio può causare l'impossibilità degli utenti di accedere o accedere a risorse sicure all'interno dell'applicazione.
  • Esposizione accidentale degli URL: se il nome host non viene mantenuto, è possibile che gli URL back-end vengano esposti agli utenti finali. Ciò può causare potenziali vulnerabilità di sicurezza e accesso non autorizzato alle informazioni riservate.
  • Problemi relativi ai cookie: i cookie svolgono un ruolo fondamentale nella gestione delle sessioni utente e nel passaggio di informazioni tra il client e il server. Quando il nome host è diverso, i cookie potrebbero non funzionare come previsto, causando problemi come l'autenticazione non riuscita, la gestione non corretta della sessione e il reindirizzamento non corretto.
  • Requisiti TLS/SSL end-to-end: se è necessario TLS/SSL end-to-end per la comunicazione sicura tra il proxy e il servizio back-end, è necessario un certificato TLS corrispondente per il nome host originale. L'uso dello stesso nome host semplifica il processo di gestione dei certificati e garantisce che la comunicazione sicura venga stabilita senza problemi.

È possibile evitare questi problemi usando lo stesso nome host per il proxy del servizio e l'applicazione Web back-end. L'applicazione back-end vede lo stesso dominio del Web browser, assicurandosi che lo stato della sessione, l'autenticazione e la gestione degli URL funzionino correttamente.

Flusso di messaggi

Il diagramma seguente illustra i passaggi per il flusso di messaggi durante la distribuzione e il runtime.

Diagramma del flusso dei messaggi della soluzione basata su Application Gateway WAFv2 e sul controller di ingresso NGINX tramite HTTPS.

Flusso di lavoro per la distribuzione

I passaggi seguenti descrivono il processo di distribuzione. Questo flusso di lavoro corrisponde ai numeri verdi nel diagramma precedente.

  1. Un tecnico della sicurezza genera un certificato per il dominio personalizzato usato dal carico di lavoro e lo salva in un insieme di credenziali delle chiavi Azure. È possibile ottenere un certificato valido da un'autorità di certificazione (CA) nota.
  2. Un tecnico della piattaforma specifica le informazioni necessarie nel file main.bicepparams Bicep parametri e distribuisce i modelli di Bicep per creare le risorse Azure. Le informazioni necessarie includono:
    • Prefisso per le risorse Azure.
    • Nome e gruppo di risorse dell'Azure Key Vault esistente che contiene il certificato TLS per il nome host del carico di lavoro e il dominio personalizzato del listener di Application Gateway.
  3. È possibile configurare lo script di distribuzione per installare i pacchetti seguenti nel cluster del servizio Azure Kubernetes. Per altre informazioni, vedere la sezione parametri del modulo Bicep.
  4. Il listener di Application Gateway recupera il certificato TLS da Azure Key Vault.
  5. L'oggetto Kubernetes Ingress usa il certificato ottenuto dal provider di Azure Key Vault per Secrets Store CSI Driver per esporre il servizio dell'interfaccia utente di Yelb tramite HTTPS.
  6. Il listener di Application Gateway recupera il certificato TLS da Azure Key Vault.
  7. L'oggetto ingress di Kubernetes utilizza il certificato ottenuto dal provider Azure Key Vault per Secrets Store CSI Driver per esporre il servizio dell'interfaccia utente di Yelb tramite HTTPS.

Carico di lavoro del runtime

  1. L'applicazione client chiama l'applicazione Web di esempio usando il nome host. La zona DNS associata al dominio personalizzato del listener del Gateway applicazione usa un record A per risolvere la query DNS nell'indirizzo IP pubblico di Azure usato dalla configurazione IP front-end del Gateway applicazione.
  2. La richiesta viene inviata all'indirizzo IP pubblico di Azure usato per la configurazione IP front-end di Application Gateway.
  3. Application Gateway esegue le operazioni seguenti:
    1. Il gateway applicativo gestisce la terminazione TLS e comunica con l'applicazione di back-end attraverso HTTPS.
    2. Il listener del gateway applicazione usa un certificato SSL ottenuto da Azure Key Vault.
    3. Il criterio WAF Azure associato al listener esegue regole OWASP e regole personalizzate contro la richiesta in ingresso e blocca gli attacchi dannosi.
    4. Le impostazioni HTTP del back-end di Application Gateway sono configurate per chiamare l'applicazione web di esempio tramite HTTPS sulla porta 443.
  4. Il pool di backend di Application Gateway contatta il controller Ingress NGINX tramite il bilanciatore del carico interno di AKS usando HTTPS.
  5. La richiesta viene inviata a uno dei nodi dell'agente che ospita un pod del controller di ingresso NGINX.
  6. Una delle repliche del controller di ingresso NGINX gestisce la richiesta e invia la richiesta a uno degli endpoint di servizio del yelb-ui servizio.
  7. Il yelb-ui chiama il servizio yelb-appserver.
  8. yelb-appserver chiama i servizi yelb-db e yelb-cache.
  9. yelb-ui chiama il servizio yelb-appserver.
  10. yelb-appserver chiama i servizi yelb-db e yelb-cache.

Distribuzione

Per impostazione predefinita, i modelli Bicep installano il cluster AKS con il plug-in di rete Azure CNI Overlay e il piano dati Cilium. È possibile usare un plug-in di rete alternativo. Inoltre, il progetto illustra come distribuire un cluster del servizio Azure Kubernetes con le estensioni e le funzionalità seguenti:

In un ambiente di produzione, consigliamo vivamente di distribuire un cluster AKS privato con SLA di uptime. Per altre informazioni, vedi cluster AKS privato con un indirizzo DNS pubblico.

In alternativa, è possibile distribuire un cluster del servizio Azure Kubernetes pubblico e proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati. Per informazioni dettagliate e istruzioni su come distribuire l'infrastruttura in Azure usando modelli di Bicep, vedere l'esempio di codice Azure complementare.

In un ambiente di produzione, consigliamo vivamente di distribuire un cluster AKS privato con SLA per il tempo di attività. Per altre informazioni, vedere cluster AKS privato con un indirizzo DNS pubblico. In alternativa, è possibile distribuire un cluster del servizio Azure Kubernetes pubblico e proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati. Per informazioni dettagliate e istruzioni su come distribuire l'infrastruttura in Azure usando modelli di Bicep, vedere l'esempio di codice Azure complementare.

Passo successivo

Distribuire un carico di lavoro dell'applicazione Web AWS in Azure

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno originariamente scritto:

Autore principale:

Altri contributori:

  • Last updated on