Usare Firewall di Azure per proteggere un cluster Servizio Azure Kubernetes (AKS)

Firewall di Azure
Servizio Azure Kubernetes (AKS)
Collegamento privato di Azure
Rete virtuale di Azure
Azure DevOps

Questa guida descrive come creare un cluster privato di AKS in una topologia di rete hub-and-spoke usando Terraform e Azure DevOps. Firewall di Azure controlla il traffico da e verso il cluster Servizio Azure Kubernetes (AKS). Il cluster è ospitato da una o più reti virtuali spoke collegate tramite peering alla rete virtuale hub.

Architettura

Diagramma che mostra un'architettura con un cluster A K S privato in una topologia di rete hub-spoke.

Scaricare un file Visio di questa architettura.

Flusso di lavoro

I moduli Terraform distribuiscono una nuova rete virtuale con quattro subnet che ospitano:

  • Cluster AKS (AksSubnet).
  • Una macchina virtuale jumpbox e endpoint privati (VmSubnet).
  • AppGatewaySubnet: firewall applicazioni Web (WAF) versione 2 del gateway delle applicazioni
  • Azure Bastion (AzureBastionSubnet)

Il cluster del servizio Azure Kubernetes usa un'identità gestita definita dall'utente per creare risorse aggiuntive, ad esempio servizi di bilanciamento del carico e dischi gestiti in Azure. I moduli Terraform consentono di distribuire facoltativamente un cluster del servizio Azure Kubernetes con queste funzionalità:

Il cluster AKS è composto dai seguenti pool di nodi:

  • Un pool di nodi di sistema che ospita solo servizi e pod di sistema critici.
  • Un pool di nodi utente che ospita i carichi di lavoro e gli artefatti degli utenti.

Una VM viene distribuita nella rete virtuale che ospita il cluster AKS. Quando si distribuisce AKS come cluster privato, gli amministratori di sistema possono utilizzare questa macchina virtuale per gestire il cluster via lo strumento della riga di comando Kubernetes. I log di diagnostica di avvio della macchina virtuale vengono archiviati in un account Archiviazione di Azure.

Un host Azure Bastion offre una migliore connettività SSH per la sicurezza alla macchina virtuale jump box tramite SSL (Secure Sockets Layer). Registro Azure Container viene usato per compilare, archiviare e gestire immagini e artefatti del contenitore ,ad esempio grafici Helm.

Il servizio Azure Kubernetes (AKS) non offre una soluzione predefinita per proteggere il traffico di ingresso e di uscita tra il cluster e le reti esterne.

Per questo motivo, l'architettura presentata in questo articolo include un Firewall di Azure che controlla il traffico in ingresso con regole DNAT (Network Address Translation) e il traffico in uscita con regole di rete e applicazioni. Il firewall applica la conversione degli indirizzi di rete di origine (SNAT) ai flussi in uscita dal cluster, sostituendo l'IP del pod con uno degli indirizzi IP pubblici del firewall, che diventa l'identità in uscita del cluster per l'elenco di elementi consentiti dai partner. Il firewall protegge anche i carichi di lavoro usando il filtro basato su intelligence sulle minacce. Firewall di Azure e Bastion vengono distribuiti in una rete virtuale hub che ha un peering con la rete virtuale che ospita il cluster AKS privato. Una tabella di routing e i percorsi definiti dall'utente indirizzano il traffico in uscita dal cluster AKS al firewall di Azure.

Nota

È consigliabile usare lo SKU Premium di Firewall di Azure perché fornisce advanced threat protection.

Un Key Vault viene usato come archivio segreto da parte dei carichi di lavoro eseguiti su AKS per recuperare chiavi, certificati e segreti tramite ID dei carichi di lavoro di Microsoft Entra, Secrets Store CSI Driver o Dapr. collegamento privato di Azure consente ai carichi di lavoro AKS di accedere ai servizi di piattaforma come servizio (PaaS) di Azure, ad esempio Azure Key Vault, attraverso un endpoint privato nella rete virtuale.

La topologia include endpoint privati e zone DNS private per questi servizi:

Esiste un collegamento di rete virtuale tra la rete virtuale che ospita il cluster del servizio Azure Kubernetes e le zone DNS private descritte in precedenza.

Un'area di lavoro Log Analytics viene usata per raccogliere i log di diagnostica e le metriche dai servizi di Azure.

Componenti

  • Firewall di Azure è un servizio di sicurezza del firewall di rete intelligente nativo del cloud che fornisce la protezione dalle minacce per i carichi di lavoro cloud eseguiti in Azure. In questa architettura, Firewall di Azure fornisce sia l'ispezione del traffico est-ovest che nord-sud. Usa regole DNAT per pubblicare flussi in ingresso in carichi di lavoro privati, regole di rete e applicazione per filtrare i flussi in uscita e SNAT per convertire il traffico in uscita negli indirizzi IP pubblici. Protegge anche i carichi di lavoro usando il filtro basato su intelligence sulle minacce nella rete virtuale hub.

  • Container Registry è un servizio di registro Docker gestito e privato basato sulla registrazione open source Docker Registry 2.0. In questa architettura, il Registro dei Container viene utilizzato per costruire, archiviare e gestire le immagini e gli artefatti dei container, come i grafici Helm, distribuiti nel cluster AKS, con supporto per la replica geografica per gli scenari di ripristino di emergenza.

  • AKS è un servizio Kubernetes gestito che semplifica la distribuzione e la gestione dei cluster Kubernetes. In questa architettura, AKS ospita il cluster privato con pool di nodi di sistema e utente in una rete virtuale spoke.

  • Key Vault è un servizio basato sul cloud che archivia e controlla l'accesso a segreti come chiavi API, password, certificati e chiavi crittografiche con maggiore sicurezza. In questa architettura, Key Vault funge da archivio segreto per i carichi di lavoro eseguiti su AKS.

  • Azure Bastion è un PaaS completamente gestito che fornisce connettività SSH (Desktop remoto Protocol) e Secure Shell (SSH) alle macchine virtuali nella rete virtuale, direttamente dal portale Azure tramite TLS. In questa architettura, Azure Bastion fornisce accesso più sicuro alla macchina virtuale jump box tramite SSL dal portale di Azure, eliminando così la necessità di esporre le macchine virtuali direttamente a Internet pubblico.

  • Macchine virtuali di Azure è un servizio di calcolo che fornisce risorse di calcolo su richiesta e scalabili che offrono la flessibilità della virtualizzazione. In questa architettura, le macchine virtuali fungono da host jump box distribuiti nella rete virtuale che ospita il cluster AKS. Consente agli amministratori di sistema di gestire il cluster privato tramite kubectl quando l'accesso diretto al server API è limitato.

  • Rete virtuale di Azure è il blocco costitutivo fondamentale per le reti private di Azure. Rete virtuale consente alle risorse di Azure, ad esempio le macchine virtuali, di comunicare tra loro, Internet e reti locali con una maggiore sicurezza. In questa architettura, Rete virtuale fornisce isolamento e connettività di rete con la rete spoke che ospita il cluster AKS e le subnet per i diversi componenti. È collegato alla rete hub che include Firewall di Azure e Azure Bastion.

  • Interfacce di rete virtuali sono componenti di rete che consentono alle macchine virtuali di Azure di comunicare con Internet, Azure e risorse locali. In questa architettura, le interfacce di rete forniscono connettività per la VM jump box e i nodi AKS. È possibile aggiungere più schede di interfaccia di rete a una macchina virtuale Azure, in modo che le macchine virtuali figlio possano avere dispositivi e indirizzi IP dedicati dell'interfaccia di rete.

  • I dischi gestiti di Azure sono volumi di archiviazione a livello di blocco gestiti da Azure nelle macchine virtuali di Azure. Sono disponibili dischi Ultra, SSD Premium, SSD Standard e HDD Standard. In questa architettura i dischi gestiti forniscono spazio di archiviazione permanente per la macchina virtuale jump box e i nodi del cluster del servizio Azure Kubernetes.

  • gestione rete virtuale di Azure è una soluzione di archiviazione oggetti per il cloud. gestione rete virtuale di Azure è ottimizzato per l'archiviazione di grandi quantità di dati non strutturati. In questa architettura gestione rete virtuale di Azure archivia i log di diagnostica di avvio della macchina virtuale jump box.

  • collegamento privato è un servizio di rete che consente di accedere ai servizi PaaS Azure tramite un endpoint privato nella rete virtuale. In questa architettura, collegamento privato offre connettività sicura ai servizi come gestione rete virtuale di Azure, Registro Container e Key Vault. Garantisce che il traffico rimanga sul backbone Azure senza esposizione alla rete Internet pubblica. È anche possibile usarlo per accedere ai servizi ospitati Azure di cui si è proprietari o che un partner Microsoft fornisce.

Alternative

È possibile usare un firewall di terze parti dal Microsoft Marketplace anziché Firewall di Azure. In tal caso, è responsabilità dell'utente configurare correttamente il firewall per ispezionare e consentire o negare il traffico entrante e uscente dal cluster AKS.

Dettagli dello scenario

I cluster AKS sono distribuiti in una rete virtuale, che può essere gestita o personalizzata. In ogni caso, il cluster presenta dipendenze in uscita da servizi esterni alla rete virtuale. Per scopi operativi e di gestione, i nodi del cluster di AKS devono accedere a porte specifiche e a nomi di dominio completi (FQDN) associati a queste dipendenze in uscita. Ciò include l'accesso al server API Kubernetes del cluster, il download e l'installazione dei componenti del cluster e il pull delle immagini dei contenitori da Registro Contenitori Microsoft. Queste dipendenze in uscita vengono definite con FQDN e non dispongono di indirizzi statici, rendendo impossibile bloccare il traffico in uscita usando i gruppi di sicurezza di rete. Pertanto, per impostazione predefinita, i cluster del servizio Azure Kubernetes dispongono di accesso a Internet in uscita (in uscita) senza restrizioni per consentire ai nodi e ai servizi di accedere alle risorse esterne in base alle esigenze.

Tuttavia, in un ambiente di produzione, in genere è consigliabile proteggere il cluster Kubernetes dall'esfiltrazione dei dati e da altri traffico di rete indesiderato. Tutto il traffico di rete, sia in entrata che in uscita, deve essere controllato in base alle regole di sicurezza. A tale scopo, il traffico in uscita deve essere limitato, consentendo comunque l'accesso alle porte e agli indirizzi necessari per le attività di manutenzione del cluster di routine, le dipendenze in uscita e i requisiti del carico di lavoro.

Una soluzione semplice consiste nell'utilizzare un dispositivo firewall in grado di controllare il traffico in uscita in base ai nomi di dominio. Un firewall crea una barriera tra una rete attendibile e Internet. Usare Firewall di Azure per limitare il traffico in uscita in base all'FQDN, al protocollo e alla porta della destinazione, fornendo un controllo del traffico in uscita con granularità fine. Consente anche l'inserimento in una lista di autorizzazione di FQDN associati alle dipendenze di uscita di un cluster AKS, cosa che non è possibile con i gruppi di sicurezza di rete. Inoltre, il filtro basato sull'intelligence sulle minacce su Firewall di Azure distribuito in una rete perimetrale condivisa può controllare il traffico in ingresso e migliorare la sicurezza. Questo filtraggio può generare avvisi e negare il traffico da e verso indirizzi IP e domini notoriamente dannosi.

È possibile creare un cluster AKS privato in una topologia di rete hub-and-spoke usando Terraform e Azure DevOps. Firewall di Azure controlla il traffico da e verso il cluster Servizio Azure Kubernetes (AKS). Il cluster è ospitato da una o più reti virtuali spoke collegate tramite peering alla rete virtuale hub.

Firewall di Azure supporta tre SKU diversi per soddisfare un'ampia gamma di casi d'uso e preferenze dei clienti:

  • Firewall di Azure Premium è consigliabile proteggere applicazioni altamente sensibili, ad esempio l'elaborazione dei pagamenti. Supporta funzionalità avanzate di protezione dalle minacce, ad esempio malware e ispezione TLS.
  • Firewall di Azure Standard è consigliato per i clienti che cercano un firewall di livello 3-livello 7 e che necessitano del ridimensionamento automatico per gestire periodi di traffico di picco fino a 30 Gbps. Supporta funzionalità aziendali, ad esempio intelligence per le minacce, proxy DNS, DNS personalizzato e categorie Web.
  • Firewall di Azure Basic consigliato per i clienti con esigenze di velocità effettiva inferiori a 250 Mbps.

La tabella seguente illustra le funzionalità dei tre SKU Firewall di Azure. Per altre informazioni, vedere Firewall di Azure prezzi.

Screenshot che mostra le funzionalità dei tre SKU Firewall di Azure

Per impostazione predefinita, i cluster del servizio Azure Kubernetes hanno accesso a Internet in uscita senza restrizioni. Questo livello di accesso alla rete consente a nodi e servizi in esecuzione nel cluster AKS di accedere alle risorse esterne in base alle esigenze. Se si vuole limitare il traffico in uscita, è necessario rendere accessibile un numero limitato di porte e indirizzi per mantenere l'integrità delle attività di manutenzione del cluster. Il modo più semplice per garantire la sicurezza per il traffico in uscita da un cluster Kubernetes come il servizio Azure Kubernetes consiste nell'usare un firewall software in grado di controllare il traffico in uscita in base ai nomi di dominio. Firewall di Azure è possibile limitare il traffico HTTP e HTTPS in uscita in base al nome di dominio completo (FQDN) della destinazione. Configurare le regole di sicurezza e del firewall preferite per consentire le porte e gli indirizzi richiesti. Per altre informazioni, vedere Configurare il traffico in uscita per i nodi del cluster in AKS (servizio Azure Kubernetes).

Analogamente, è possibile controllare il traffico in ingresso e migliorare la sicurezza abilitando il filtraggio basato su intelligence sulle minacce in un firewall di Azure distribuito in una rete perimetrale condivisa. Questo filtraggio può generare avvisi e negare il traffico da e verso indirizzi IP e domini notoriamente dannosi.

Potenziali casi d'uso

Questo scenario risolve la necessità di migliorare la sicurezza del traffico in ingresso e in uscita da e verso un cluster Kubernetes.

Evitare il routing asimmetrico

In questa soluzione, Firewall di Azure viene distribuito in una rete virtuale hub e il cluster privato di Azure Kubernetes Service (AKS) viene distribuito in una rete virtuale spoke. Firewall di Azure usa raccolte di regole di rete e applicazione per controllare il traffico in uscita. In questo caso, è necessario configurare il traffico in ingresso a qualsiasi endpoint pubblico esposto da qualsiasi servizio in esecuzione su AKS per accedere al sistema attraverso uno degli indirizzi IP pubblici usati dal Firewall di Azure.

I pacchetti arrivano sull'indirizzo IP pubblico del firewall, ma tornano al firewall tramite l'indirizzo IP privato usando la route predefinita. Questo è un problema. Per evitarlo, creare un'altra route definita dall'utente per l'indirizzo IP pubblico del firewall, come illustrato nel diagramma seguente. I pacchetti trasmessi all'indirizzo IP pubblico del firewall vengono instradati tramite Internet. Questa configurazione evita di usare la route predefinita per indirizzo IP privato del firewall.

Per instradare il traffico dei carichi di lavoro dell'AKS al Firewall di Azure nella rete virtuale hub, è necessario:

  • Creare e associare una tabella di route a ogni subnet che ospita i nodi di lavoro del cluster.
  • Creare una route definita dall'utente per inoltrare il traffico per 0.0.0.0/0 CIDR all'indirizzo IP privato del Firewall di Azure. Specificare l'appliance virtuale per il tipo di hop successivo.

Per altre informazioni, vedere Tutorial: Distribuire e configurare Firewall di Azure tramite il portale di Azure.

Diagramma che illustra come evitare il routing asimmetrico quando si usa Firewall di Azure davanti ai carichi di lavoro.

Per altre informazioni, vedi:

Distribuire i carichi di lavoro in un cluster del servizio Azure Kubernetes privato quando si usa Azure DevOps

Se si usa Azure DevOps, non è possibile usare Azure DevOps agenti ospitati da Microsoft per distribuire i carichi di lavoro in un cluster del servizio Azure Kubernetes privato. Non hanno accesso al server API. Per distribuire carichi di lavoro nel vostro cluster AKS privato, dovete effettuare il provisioning e utilizzare un agente self-hosted di Azure DevOps nella stessa rete virtuale del vostro cluster AKS privato o in una rete virtuale in peering. Nel secondo caso, assicurarsi di creare un collegamento di rete virtuale tra la zona DNS privata del cluster AKS nel gruppo di risorse del nodo e la rete virtuale che ospita l'agente self-hosted di Azure DevOps.

È possibile distribuire un singolo agente Windows o Linux Azure DevOps in una macchina virtuale oppure è possibile usare un set di scalabilità di macchine virtuali. Per ulteriori informazioni, vedere Agenti di set di scalabilità di macchine virtuali Azure. In alternativa, è possibile configurare un agente self-hosted in Azure Pipelines per l'esecuzione all'interno di un contenitore Windows Server Core (per gli host Windows) o di un contenitore Ubuntu (per gli host Linux) con Docker. Distribuiscilo come pod con una o più repliche nel tuo cluster AKS privato. Per altre informazioni, vedi:

Se le subnet che ospitano i pool di nodi del cluster privato AKS sono configurate per instradare il traffico in uscita a un Firewall di Azure tramite una tabella di route e una route definita dall'utente, assicurarsi di creare le regole di applicazione e di rete corrette. Queste regole devono consentire all'agente di accedere a siti esterni per scaricare e installare strumenti come Docker, Kubectl, interfaccia della riga di comando di Azure e Helm nella macchina virtuale dell'agente. Per ulteriori informazioni, guardare Eseguire un agente ospitato autonomamente in Docker.

Diagramma che mostra la distribuzione di carichi di lavoro in un cluster del servizio Azure Kubernetes privato da usare con Azure DevOps.

In alternativa, è possibile configurare un pool DevOps gestito (MDP) nella rete virtuale che ospita il cluster AKS o in una rete virtuale con peering. I pool DevOps gestiti consentono ai team di sviluppo di creare pool di agenti Azure DevOps personalizzati in base alle esigenze specifiche. Implementa le procedure consigliate per la sicurezza, offre opzioni per bilanciare i costi e le prestazioni, offre percorsi per scenari comuni e riduce significativamente il tempo dedicato alla creazione e alla gestione di pool personalizzati. Per altre informazioni, vedere Panoramica dell'architettura dei pool di DevOps gestiti da Microsoft.

È possibile aggiungere agenti da un pool DevOps gestito nella rete virtuale, consentendo alle pipeline CI/CD di interagire con il server API Kubernetes del cluster privato AKS e di accedere alle risorse di Azure, ad esempio Registro Azure Container, quando l'accesso alla rete pubblica è disabilitato e sono raggiungibili solo tramite un endpoint privato definito nella stessa rete virtuale o in una rete collegata tramite peering. Per altre informazioni, vedere Configurare la rete dei pool DevOps gestiti.

Usare Firewall di Azure davanti a un servizio di bilanciamento del carico pubblico

Le definizioni delle risorse nei moduli Terraform usano il meta-argomento lifecycle per personalizzare le azioni quando le risorse Azure vengono modificate al di fuori del controllo Terraform. L'argomento ignore_changes viene usato per indicare a Terraform di ignorare gli aggiornamenti alle proprietà delle risorse, ad esempio i tag. La definizione della risorsa di Firewall di Azure Policy contiene un blocco del ciclo di vita per impedire a Terraform di aggiornare la risorsa quando una raccolta di regole o una singola regola viene creata, aggiornata o eliminata. Analogamente, la tabella di route Azure contiene un blocco del ciclo di vita per impedire a Terraform di aggiornare la risorsa quando viene creata, eliminata o aggiornata una route definita dall'utente. In questo modo è possibile amministrare il DNAT, le applicazioni e le regole di rete di una politica di firewall di Azure e le route definite dall'utente in una tabella di route di Azure al di fuori del controllo di Terraform.

Questo diagramma mostra la topologia di rete dell'esempio:

Diagramma che mostra Firewall di Azure davanti a un servizio di bilanciamento del carico pubblico.

Ecco il flusso del messaggio:

  1. Una richiesta per l'applicazione Web ospitata in AKS viene inviata a un indirizzo IP pubblico esposto da Firewall di Azure tramite una configurazione IP pubblica. Sia l'indirizzo IP pubblico che la configurazione IP pubblico sono dedicati a questo carico di lavoro.
  2. Una regola DNAT di Firewall di Azure traduce l'indirizzo IP pubblico e la porta di Firewall di Azure nell'indirizzo IP pubblico e nella porta utilizzati dal carico di lavoro nel bilanciatore del carico pubblico del cluster AKS nel gruppo di risorse del nodo.
  3. Il bilanciatore del carico invia la richiesta a uno dei pod del servizio Kubernetes in esecuzione in uno dei nodi agente del cluster AKS.
  4. Il messaggio di risposta viene inviato al chiamante originale tramite una route definita dall'utente. L'indirizzo IP pubblico di Firewall di Azure è il prefisso dell'indirizzo e Internet è il tipo di hop successivo .
  5. Qualsiasi chiamata in uscita avviata dal carico di lavoro viene instradata all'indirizzo IP privato del Firewall di Azure dalla route predefinita definita dall'utente. 0.0.0.0/0 è il prefisso dell'indirizzo e l'appliance virtuale è il tipo di hop successivo.

Usare Firewall di Azure davanti a un servizio di bilanciamento del carico interno

In questo scenario, un'applicazione ASP.NET Core è ospitata come servizio da un cluster AKS e gestita da un controller di ingresso NGINX. Il ingress controller NGINX viene esposto tramite un bilanciatore di carico interno con un indirizzo IP privato nella rete virtuale spoke che ospita il cluster AKS. Per altre informazioni, vedere Creare un controller di ingresso in una rete virtuale interna nel servizio Azure Kubernetes. Quando si distribuisce un controller di ingresso NGINX o più in genere un LoadBalancer servizio o ClusterIP , con l'annotazione service.beta.kubernetes.io/azure-load-balancer-internal: "true" nella sezione dei metadati, viene creato un servizio di bilanciamento del carico interno denominato kubernetes-internal nel gruppo di risorse del nodo. Per altre informazioni, vedere Utilizzare un bilanciatore di carico interno con AKS. Come illustrato nel diagramma seguente, l'applicazione Web di test viene esposta dal Firewall di Azure con un indirizzo IP pubblico dedicato Azure.

Diagram che mostra Firewall di Azure davanti a un *internal load balancer*.

Ecco il flusso del messaggio:

  1. Una richiesta per l'applicazione Web di test ospitata da AKS viene inviata a un indirizzo IP pubblico esposto dal firewall di Azure tramite una configurazione IP pubblica. Sia l'indirizzo IP pubblico che la configurazione IP pubblico sono dedicati a questo carico di lavoro.
  2. Una regola DNAT di Firewall di Azure converte l'IP pubblico e la porta di Firewall di Azure nell'IP privato e nella porta utilizzati dal controller di ingresso NGINX nel bilanciatore di carico interno del cluster AKS nel gruppo di risorse del nodo.
  3. La richiesta viene inviata dal servizio di bilanciamento del carico interno a uno dei pod del servizio Kubernetes in esecuzione in uno dei nodi agente del cluster AKS.
  4. Il messaggio di risposta viene inviato al chiamante originale tramite una route definita dall'utente. 0.0.0.0/0 è il prefisso dell'indirizzo e l'appliance virtuale è il tipo di hop successivo.
  5. Qualsiasi chiamata in uscita avviata dal carico di lavoro viene instradata all'indirizzo IP privato della route definita dall'utente.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Alcune delle considerazioni seguenti sono raccomandazioni generali che non sono specifiche per l'uso di Firewall di Azure per migliorare la protezione di un cluster del servizio Azure Kubernetes. Riteniamo che siano requisiti essenziali di questa soluzione. Sono incluse considerazioni su sicurezza, prestazioni, disponibilità e affidabilità, archiviazione, mesh di servizi e monitoraggio.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

La piattaforma Azure offre una migliore protezione da varie minacce, ad esempio intrusioni di rete e attacchi DDoS (Distributed Denial of Service). È consigliabile usare un Web application firewall (WAF) per fornire protezione per tutte le applicazioni e i servizi Web ospitati dal servizio Azure Kubernetes che espongono un endpoint HTTPS pubblico. È necessario fornire protezione da minacce comuni, ad esempio SQL injection, scripting tra siti e altri exploit Web. A tale scopo, usare regole OWASP (Open Web Application Security Project) e regole personalizzate. Web application firewall di Azure offre una migliore protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. È possibile distribuire Azure WAF con gateway applicazione di Azure, Frontdoor di Azure e Rete di distribuzione dei contenuti di Azure.

Gli attacchi DDoS sono tra i principali problemi di disponibilità e sicurezza che devono affrontare le organizzazioni che spostano le applicazioni nel cloud. Un attacco DDoS tenta di esaurire le risorse di un'applicazione, che quindi non risulta più disponibile per gli utenti legittimi. Gli attacchi DDoS possono avere come obiettivo qualsiasi endpoint raggiungibile pubblicamente tramite Internet. Ogni proprietà in Azure include la protezione dell'infrastruttura DDoS di Azure senza costi aggiuntivi. La scalabilità e la capacità della rete Azure distribuita a livello globale offre una migliore difesa dagli attacchi comuni a livello di rete tramite il monitoraggio del traffico always-on e la mitigazione in tempo reale. La protezione dell'infrastruttura DDoS non richiede modifiche alla configurazione utente o all'applicazione. Consente di proteggere tutti i servizi Azure, inclusi i servizi PaaS come DNS di Azure.

Azure Protezione di rete DDoS, combinata con le procedure consigliate per la progettazione delle applicazioni, offre funzionalità avanzate di mitigazione DDoS per offrire maggiore difesa dagli attacchi DDoS. È necessario abilitare Azure Protezione di rete DDOS in qualsiasi rete virtuale perimetrale.

Di seguito sono riportate alcune considerazioni aggiuntive sulla sicurezza:

  • Creare un endpoint privato per qualsiasi servizio PaaS usato dai carichi di lavoro di Azure Kubernetes Service (AKS), ad esempio Key Vault, bus di servizio di Azure e database SQL di Azure. In questo modo il traffico tra le applicazioni e questi servizi non viene esposto alla rete Internet pubblica. Il traffico tra la rete virtuale del cluster AKS e un'istanza di un servizio PaaS tramite un endpoint privato viaggia attraverso la rete backbone Microsoft, ma la comunicazione non passa dal firewall di Azure. Questo meccanismo offre una maggiore sicurezza e una migliore protezione contro la perdita di dati. Per altre informazioni, vedere Che è collegamento privato di Azure?.
  • Quando si usa Application Gateway davanti al cluster del servizio Azure Kubernetes, usare un Web application firewall Policy per proteggere i carichi di lavoro pubblici eseguiti nel servizio Azure Kubernetes da attacchi.
  • Usare i criteri di rete per separare e proteggere le comunicazioni all'interno dei servizi controllando quali componenti possono comunicare tra loro. Per impostazione predefinita, tutti i pod in Kubernetes possono inviare e ricevere traffico senza limitazioni. Per migliorare la sicurezza, è possibile usare Azure criteri di rete o criteri di rete Calico per definire regole che controllano il flusso di traffico tra microservizi diversi. Per altre informazioni, vedere Criteri di rete.
  • Non esporre la connettività remota ai nodi di AKS. Creare un bastion host o una jump box in una rete virtuale di gestione. Usa un host bastion per indirizzare il traffico nel tuo cluster AKS.
  • È consigliabile usare un cluster del servizio Azure Kubernetes privato nell'ambiente di produzione o almeno proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati nel servizio Azure Kubernetes. Quando si utilizzano intervalli di indirizzi IP autorizzati in un cluster pubblico, è necessario autorizzare tutti gli indirizzi IP in uscita nella raccolta di regole della rete di Firewall di Azure. Le operazioni nel cluster usano il server API Kubernetes.
  • Se si abilita DNS proxy in Firewall di Azure, Firewall di Azure può elaborare e inoltrare query DNS da una o più reti virtuali a un server DNS scelto. Questa funzionalità è fondamentale e necessaria per un filtro FQDN affidabile nelle regole di rete. È possibile abilitare il proxy DNS nelle impostazioni di Firewall di Azure e criteri firewall. Per ulteriori informazioni sui log proxy DNS, vedere log e metriche di Firewall di Azure.
  • Quando si usa Firewall di Azure davanti a Application Gateway, è possibile configurare la risorsa di ingresso Kubernetes per esporre i carichi di lavoro tramite HTTPS e usare un sottodominio separato e un certificato digitale per ogni tenant. Il controller di ingresso del gateway applicazione configura automaticamente il listener del gateway applicazione per la terminazione SSL.
  • È possibile usare Firewall di Azure davanti a un proxy del servizio, ad esempio il controller di ingresso NGINX. Questo controller fornisce proxy inverso, instradamento del traffico configurabile e terminazione TLS per i servizi Kubernetes. Le risorse di ingresso Kubernetes vengono usate per configurare le regole di ingresso e le route per i singoli servizi Kubernetes. Usando un controller Ingress e regole Ingress, è possibile usare un singolo indirizzo IP per instradare il traffico a più servizi in un cluster Kubernetes. È possibile generare i certificati TLS usando un'autorità di certificazione riconosciuta. In alternativa, è possibile utilizzare Let's Encrypt per generare automaticamente certificati TLS con un indirizzo IP pubblico dinamico o con un indirizzo IP pubblico statico. Per altre informazioni, vedere Creare un controller di ingresso HTTPS e usare i propri certificati TLS nel servizio Azure Kubernetes.
  • Il coordinamento rigoroso tra l'operatore Firewall di Azure e i team del cluster e del carico di lavoro è necessario sia per la distribuzione iniziale del cluster sia in modo continuativo man mano che le esigenze del carico di lavoro e del cluster si evolvono. Ciò vale soprattutto quando si configurano i meccanismi di autenticazione, ad esempio OAuth 2.0 e OpenID Connect, usati dai carichi di lavoro per autenticare i client.
  • Usare le linee guida seguenti per proteggere l'ambiente descritto in questo articolo:

Disponibilità e affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Le considerazioni sulla disponibilità e sull'affidabilità non sono specifiche per il multitenancy in AKS. Riteniamo che siano requisiti essenziali di questa soluzione. Considera i metodi seguenti per ottimizzare la disponibilità del tuo cluster AKS e dei carichi di lavoro.

Resilienza all'interno dell'area

  • Durante la distribuzione, è possibile configurare Firewall di Azure per estendersi su più zone di disponibilità per una maggiore disponibilità. Per le percentuali di disponibilità, consultare l'SLA di Firewall di Azure nei Contratti di Livello di Servizio per Microsoft Online Services. È anche possibile associare Firewall di Azure a una zona specifica per motivi di prossimità, anche se questa configurazione influisce sul contratto di servizio. Non sono previsti costi aggiuntivi per un firewall distribuito in una zona di disponibilità, inclusi i trasferimenti di dati della zona tra disponibilità.
  • Considera di distribuire i pool di nodi del cluster AKS in tutte le zone di disponibilità in una regione. Usare un Azure Load Balancer o Application Gateway davanti ai pool di nodi. Questa topologia offre migliore resilienza nell'eventualità di un'interruzione di un singolo data center. In questo modo, i nodi del cluster vengono distribuiti tra più data center, in tre zone di disponibilità separate all'interno di un'area.
  • Abilitare la ridondanza zonale nel Registro contenitori per garantire resilienza all'interno dell'area e alta disponibilità.
  • Usare i vincoli di distribuzione della topologia dei pod per controllare come i pod vengono distribuiti nel cluster AKS tra diversi domini di errore, come regioni, zone di disponibilità e nodi.
  • Prendere in considerazione l'utilizzo dello SLA di disponibilità per i cluster del servizio Azure Kubernetes Service (AKS) che ospitano carichi di lavoro di importanza critica. Il SLA di Uptime è una funzionalità facoltativa che consente di ottenere un SLA più alto e finanziariamente supportato per un cluster. SLA garantisce l'alta disponibilità dell'endpoint del server API Kubernetes per i cluster che utilizzano le zone di disponibilità. È anche possibile usarlo per i cluster che non usano zone di disponibilità, ma il contratto di servizio è inferiore. Per i dettagli sul SLA, vedere Uptime SLA. Azure Kubernetes Service (AKS) usa le repliche dei nodi master nei domini di aggiornamento e di errore per garantire che siano soddisfatti i requisiti SLA.

Ripristino di emergenza e continuità aziendale

  • Valutare la possibilità di distribuire la soluzione in almeno due aree accoppiate di Azure all'interno di un'area geografica. Usare un servizio di bilanciamento del carico globale, ad esempio Gestione traffico di Azure o Frontdoor di Azure, con un metodo di routing attivo/attivo o attivo/passivo, per garantire la continuità aziendale e il ripristino di emergenza.
  • Firewall di Azure è un servizio a livello di area. Se si distribuisce la soluzione in due o più aree, è necessario creare un Firewall di Azure in ogni area. È possibile creare un criterio di Firewall di Azure globale per includere le regole definite dall'organizzazione applicabili a tutti gli hub regionali. È possibile usare questo criterio come criterio padre per i criteri di Azure a livello di area. I criteri creati con criteri padre non vuoti ereditano tutte le raccolte di regole dai criteri padre. Le raccolte di regole di rete ereditate dai criteri padre sono sempre prioritarie rispetto alle raccolte di regole di rete definite come parte di un nuovo criterio. La stessa logica si applica anche alle raccolte di regole dell'applicazione. Le raccolte di regole di rete, tuttavia, vengono sempre elaborate prima delle raccolte di regole dell'applicazione indipendentemente dall'ereditarietà. Per altre informazioni sui criteri Standard e Premium, vedere panoramica dei criteri Gestione firewall di Azure.
  • Assicurarsi di creare script, documentare e testare periodicamente qualsiasi processo di failover regionale in un ambiente QA (Quality Assurance). In questo modo è possibile evitare problemi imprevedibili se un servizio principale è interessato da un'interruzione nell'area primaria. Questi test sono concepiti anche per convalidare se l'approccio di ripristino di emergenza soddisfa gli obiettivi RPO/RTO, in combinazione con eventuali processi e interventi manuali necessari per un failover.
  • Testare le procedure di failback per verificare che funzionino come previsto.
  • Archiviare le immagini del contenitore in Registro Container. Replicare geograficamente il registro in ogni area AKS. Per altre informazioni, vedere Geo-replication in Registro Azure Container.
  • Se possibile, evitare di archiviare lo stato del servizio nel contenitore. Usare invece un Azure PaaS che supporta la replica multiregione.
  • Se si usa Archiviazione di Azure, preparare e testare un processo per la migrazione dell'archiviazione dall'area primaria all'area di backup.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

DevOps

  • Distribuire i carichi di lavoro su AKS utilizzando un chart Helm in una pipeline di integrazione continua e consegna continua (CI/CD). Usare un sistema DevOps come GitHub Actions o Azure DevOps. Per altre informazioni, vedere Build e distribuire in servizio Azure Kubernetes.
  • Per testare correttamente un'applicazione prima di renderla disponibile agli utenti, utilizza test A/B e distribuzioni canary nella gestione del ciclo di vita dell'applicazione. È possibile usare varie tecniche per suddividere il traffico tra versioni diverse dello stesso servizio. In alternativa, è possibile usare le funzionalità di suddivisione del traffico fornite dall'implementazione di una mesh di servizi. Per altre informazioni, vedere Linkerd Traffic Split and Istio Traffic Management.For more information, see Linkerd Traffic Split and Istio Traffic Management.
  • Usare Registro Azure Container o un altro registro contenitori,ad esempio Docker Hub, per archiviare le immagini Docker private distribuite nel cluster. Azure Kubernetes Service (AKS) può autenticarsi con Registro Azure Container usando la sua identità Microsoft Entra.
  • Testare l'ingresso e l'uscita nei carichi di lavoro in un ambiente di preproduzione separato che rispecchia la topologia di rete e le regole del firewall dell'ambiente di produzione. Una strategia di implementazione a fasi consente di rilevare eventuali problemi di rete o di sicurezza prima di rilasciare una nuova funzionalità o una nuova regola di rete nell'ambiente di produzione.

Monitoraggio

Firewall di Azure è completamente integrato con Monitoraggio di Azure per la registrazione del traffico in ingresso e in uscita elaborato dal firewall. Per altre informazioni, vedere Firewall di Azure filtro basato sull'intelligence sulle minacce.

Le considerazioni di monitoraggio seguenti non sono specifiche per la multi-tenancy nel servizio Azure Kubernetes, ma riteniamo che siano requisiti essenziali per questa soluzione.

  • Usare Container insights per monitorare lo stato di integrità del cluster AKS e dei carichi di lavoro.
  • Configurare tutti i servizi PaaS (ad esempio Registro Contenitori e Key Vault) per raccogliere i log di diagnostica e le metriche.

Ottimizzazione dei costi

Il costo di questa architettura dipende da determinati aspetti di configurazione come i seguenti:

  • Livelli di servizio
  • Scalabilità, ovvero numero di istanze allocate dinamicamente dai servizi per supportare una determinata domanda
  • Script di automazione
  • Il tuo livello di ripristino in caso di emergenza

Dopo aver valutato questi dettagli di configurazione, usare il calcolatore prezzi Azure per stimare i costi. Per altre opzioni di ottimizzazione dei prezzi, vedere principle di ottimizzazione dei costi in Microsoft Azure Well-Architected Framework.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

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

Passaggi successivi

Guida al servizio Well-Architected Framework per AKS

Firewall di Azure

servizio Azure Kubernetes