Usare Firewall di Azure per aiutare a proteggere un cluster AKS

Questa guida descrive come creare un cluster Servizio Azure Kubernetes (AKS) privato in una topologia di rete hub-spoke usando Terraform e Azure DevOps. Firewall di Azure esamina il traffico da e verso il cluster AKS. La rete virtuale hub esegue il peering con una o più reti virtuali spoke che ospitano il cluster.

Architecture

Scaricare un file di Visio di questa architettura.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente:

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

Cluster AKS (AksSubnet).
Una macchina virtuale jumpbox e endpoint privati (VmSubnet).
gateway applicazione di Azure Web application firewall v2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet)

Il cluster AKS usa un'identità gestita definita dall'utente per creare altre risorse, ad esempio i bilanciatori del carico e i dischi gestiti in Azure. Utilizzando i moduli Terraform, è possibile distribuire facoltativamente un cluster AKS con le funzionalità seguenti:

Il cluster AKS è composto da:

Pool di nodi di sistema che ospita solo pod e servizi di sistema critici.
Pool di nodi utente che ospita carichi di lavoro e artefatti utente.

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 tramite lo strumento da riga di comando di Kubernetes. Un account Archiviazione di Azure archivia i log di diagnostica di avvio della macchina virtuale.

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

AKS non fornisce una soluzione integrata per proteggere il traffico in entrata e in uscita tra il cluster e le reti esterne.

Per questo motivo, l'architettura di questo articolo include un Firewall di Azure che controlla il traffico in ingresso usando le regole DNAT (Network Address Translation) di destinazione e il traffico in uscita con regole di rete e applicazione. Il firewall applica SNAT (Source Network Address Translation) ai flussi in uscita dal cluster. Sostituisce l'indirizzo IP del pod con uno degli indirizzi IP pubblici del firewall, che diventa l'identità di uscita del cluster per l'inserimento nella allowlist dei partner. Il firewall protegge anche i carichi di lavoro usando il filtro basato su intelligence sulle minacce. Firewall di Azure e Azure Bastion sono distribuiti in una rete virtuale hub connessa tramite peering alla rete virtuale che ospita il cluster AKS privato. Una tabella di routing e route definite dall'utente (UDR) instradano il traffico in uscita dal cluster AKS ad Firewall di Azure.

Annotazioni

È consigliabile usare Firewall di Azure Premium perché offre una protezione avanzata dalle minacce.

I carichi di lavoro eseguiti in AKS usano Azure Key Vault come archivio di segreti per recuperare chiavi, certificati e segreti tramite Microsoft Entra Workload Identity, Secrets Store CSI Driver o Dapr. collegamento privato di Azure consente ai carichi di lavoro di AKS di accedere ai servizi PaaS di Azure, come Key Vault, tramite un endpoint privato nella rete virtuale.

La topologia include endpoint privati e zone DNS (Domain Name System) private per questi servizi:

Un collegamento di rete virtuale collega la rete virtuale che ospita il cluster AKS alle zone DNS private descritte in precedenza.

Un'area di lavoro Log Analytics raccoglie i log di diagnostica e le metriche dai servizi di Azure.

Components

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 nel relativo indirizzo IP pubblico. 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, Container Registry crea, archivia e gestisce immagini di contenitori e artefatti come i chart Helm distribuiti nel cluster AKS. Supporta la replica geografica per scenari di ripristino di emergenza.It supports geo-replication for disaster recovery (DR) scenarios.
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 Kubernetes Service).
Azure Bastion è un PaaS completamente gestito che fornisce Desktop remoto Protocol (RDP) e connettività SSH alle macchine virtuali nella rete virtuale, direttamente dal portale di Azure su Transport Layer Security (TLS). In questa architettura, Azure Bastion fornisce un accesso più sicuro alla macchina virtuale jump box tramite TLS 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, Macchine virtuali funge da host della jump box distribuito nella rete virtuale che ospita il cluster AKS. Gli amministratori di sistema usano Macchine virtuali per gestire il cluster privato tramite kubectl quando l'accesso diretto al server API è limitato.
Rete virtuale di Azure è il blocco fondamentale per le reti private di Azure. La rete virtuale consente alle risorse di Azure, come le macchine virtuali, di comunicare tra loro, Internet e reti locali con una maggiore sicurezza. In questa architettura, la rete virtuale fornisce isolamento e connettività di rete con la rete spoke che ospita il cluster AKS e le subnet per i vari componenti. È collegato alla rete hub che include Firewall di Azure e Azure Bastion.
Le interfacce di rete virtuale sono componenti di rete che consentono alle macchine virtuali di Azure di comunicare con Internet, Azure e le risorse locali. In questa architettura, le interfacce di rete forniscono connettività per la VM jump box e i nodi AKS. È possibile aggiungere diverse NIC a una VM di Azure in modo che le VM figlio possano avere dispositivi di interfaccia di rete e indirizzi IP dedicati.
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 di Azure senza esposizione alla rete Internet pubblica. È anche possibile usarlo per accedere ai servizi ospitati in Azure di cui si è proprietari o che un partner Microsoft fornisce.

Le alternative

È possibile usare un firewall non Microsoft dal Marketplace Microsoft anziché da Firewall di Azure. Con questo approccio, è necessario configurare correttamente il firewall per controllare e consentire o negare il traffico in ingresso e in uscita dal cluster del servizio Azure Kubernetes.

Dettagli dello scenario

I cluster AKS vengono distribuiti in una rete virtuale gestita o personalizzata. Il cluster ha ancora dipendenze in uscita dai servizi all'esterno di tale rete. Ai fini della gestione e dell'operatività, i nodi del cluster del servizio Azure Kubernetes devono accedere a porte specifiche e nomi di dominio completi (FQDN) associati a queste dipendenze. Questi requisiti includono l'accesso al server API Kubernetes del cluster, l'accesso alle porte per i download dei componenti del cluster e l'accesso a Microsoft Registro Container per eseguire il pull delle immagini del contenitore. Queste dipendenze in uscita vengono definite con FQDN e non hanno indirizzi IP statici, impedendo così di bloccare il traffico in uscita usando gruppi di sicurezza di rete. Di conseguenza, i cluster del servizio Azure Kubernetes consentono l'accesso a Internet in uscita senza restrizioni per impostazione predefinita, in modo che i nodi e i servizi possano raggiungere le risorse esterne necessarie.

In un ambiente di produzione, tuttavia, è in genere preferibile proteggere il cluster Kubernetes dall'esfiltrazione di dati e da altri traffico di rete indesiderato. Tutto il traffico di rete in ingresso e in uscita deve seguire le regole di sicurezza definite. Per soddisfare questo requisito, limitare il traffico in uscita, 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 di destinazione per fornire un controllo del traffico in uscita con granularità fine. Consente inoltre di definire un elenco di elementi consentiti per gli FQDN associati alle dipendenze in uscita di un cluster AKS, operazione non possibile usando i gruppi di sicurezza di rete (NSG). 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-spoke utilizzando Terraform e Azure DevOps. Firewall di Azure ispeziona il traffico in ingresso e in uscita dal cluster 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 è consigliato per proteggere applicazioni altamente sensibili, ad esempio l'elaborazione dei pagamenti. Supporta funzionalità avanzate di protezione dalle minacce, ad esempio il rilevamento delle minacce correlate al malware e l'ispezione TLS.
Firewall di Azure Standard è consigliato per i clienti che necessitano di funzionalità firewall di livello 3 a livello 7 e scalabilità automatica che supportano il picco del traffico 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 Prezzi di 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, un numero limitato di porte e indirizzi deve rimanere raggiungibile per mantenere le attività di manutenzione del cluster integre. 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 può limitare il traffico HTTP e HTTPS in uscita in base al nome di dominio completo della destinazione. Configurare le regole di sicurezza e del firewall preferite per consentire le porte e gli indirizzi richiesti. Per ulteriori informazioni, vedere Gestire il traffico in uscita per i nodi del cluster AKS.

È anche possibile controllare il traffico in ingresso e migliorare la sicurezza abilitando il filtro basato sulla threat intelligence su 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.

Casi d'uso potenziali

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

Configurare il cluster AKS per instradare il traffico in uscita tramite Firewall di Azure

Per forzare il traffico in uscita di AKS attraverso Firewall di Azure, è necessario configurare il cluster, non solo il firewall e la tabella di routing. Prendere queste decisioni quando si crea il cluster:

Impostare il tipo in uscita su userDefinedRouting. Con questo tipo di traffico in uscita, AKS non esegue il provisioning di un bilanciatore del carico pubblico standard per il traffico in uscita e non aggiunge i propri indirizzi IP pubblici per SNAT. Tutto il traffico in uscita dalle subnet del pool di nodi segue la UDR verso l'indirizzo IP privato di Firewall di Azure, garantendo al firewall piena visibilità su ogni flusso in uscita. Per altre informazioni, vedere Configurare i tipi di traffico in uscita del cluster in AKS.
Utilizzare il tag FQDN AzureKubernetesService per l'elenco degli elementi consentiti in uscita necessario. AKS richiede l'accesso in uscita a un lungo elenco di FQDN, aggiornato frequentemente, per la comunicazione del piano di controllo, il download delle immagini, l'identità e altri servizi della piattaforma. Invece di mantenere manualmente questi FQDN, creare una regola dell'applicazione Firewall di Azure che usa il AzureKubernetesService tag FQDN. Firewall di Azure mantiene aggiornato questo tag con gli endpoint richiesti dalla piattaforma. Combinare questo tag con le regole di rete di destinazione per il protocollo NTP (Network Time Protocol), il server API su TCP 9000 e UDP 1194 e i registri contenitori usati dai carichi di lavoro.
Usare l'integrazione della rete virtuale del server API per mantenere il traffico del server API nella rete privata. L'integrazione della rete virtuale del server API proietta l'endpoint del server API in una subnet delegata nella rete virtuale. Il traffico da nodo a SERVER API rimane nella rete privata e non attraversa Firewall di Azure. Questo comportamento elimina la necessità delle regole di rete di AKS-tunnel e riduce il numero di flussi di traffico in uscita che il firewall deve ispezionare. Combinare l'integrazione della rete virtuale del server API con l'impostazione del cluster privato se si vuole bloccare anche l'accesso alla rete pubblica al server API. Per ulteriori informazioni, vedere Creare un cluster AKS con l'integrazione della rete virtuale del server API. L'integrazione della rete virtuale del server API è l'approccio consigliato per i nuovi cluster privati. L'implementazione precedente del cluster privato basata su collegamento privato è supportata, ma aggiunge complessità legate a DNS e tunnel, eliminate dall'integrazione con la rete virtuale.

Pianificare gli indirizzi IP pubblici di Firewall di Azure e la capacità SNAT

Firewall di Azure usa SNAT per tutti i flussi in uscita. Ogni indirizzo IP pubblico collegato al firewall fornisce un numero fisso di porte SNAT, circa 2.496 porte per indirizzo IP per ogni istanza back-end. Un cluster AKS di produzione genera molti flussi in uscita concorrenti dai pod, soprattutto quando i pod aprono molte connessioni di breve durata verso un numero ridotto di destinazioni esterne. Se si effettua un provisioning insufficiente degli indirizzi IP pubblici, le porte SNAT si esauriscono e le chiamate in uscita iniziano a fallire in modo intermittente con timeout di connessione difficili da diagnosticare.

Le linee guida di AKS in Limitare il traffico di rete con Firewall di Azure in AKS consigliano, per i carichi di lavoro di produzione, almeno 20 indirizzi IP pubblici front-end in Firewall di Azure per evitare l'esaurimento delle porte SNAT. Considerare questo numero come punto di partenza, non come requisito fisso. Il numero corretto dipende dalla concorrenza in uscita del carico di lavoro, dalla diversità di destinazione e dalla durata delle connessioni.
Usare l'integrazione di Firewall di Azure con NAT Gateway o associare un prefisso IP pubblico per semplificare la gestione di molti indirizzi IP pubblici ed espandere il pool di porte SNAT disponibile. NAT Gateway aumenta notevolmente la scalabilità dello SNAT ed è l'opzione preferita per il traffico in uscita ad alta concorrenza.
Monitorare l'utilizzo delle porte SNAT su Firewall di Azure e ridimensionare gli indirizzi IP pubblici nel firewall prima di raggiungere la saturazione. Per altre informazioni, vedere Monitorare Firewall di Azure.
Se un numero ridotto di carichi di lavoro domina il profilo del traffico in uscita (ad esempio, processi di inoltro dei log o scraper in esecuzione su ogni nodo ma che inviano traffico solo a uno o due endpoint), valuta un percorso di uscita dedicato tramite un gateway di uscita statico anziché aumentare gli indirizzi IP del firewall per adattarsi a un singolo carico di lavoro che genera molto traffico.

Evitare il routing asimmetrico

In questa soluzione, Firewall di Azure viene distribuito in una rete virtuale hub e il cluster AKS privato 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, configurare il traffico in ingresso diretto a qualsiasi endpoint pubblico esposto da qualsiasi servizio in esecuzione in AKS in modo che entri nel sistema tramite uno degli indirizzi IP pubblici usati da 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. Per evitare questo problema, creare un'altra UDR per l'indirizzo IP pubblico del firewall, come illustrato nel diagramma seguente. I pacchetti che passano 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 del tuo 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 UDR per instradare il traffico di 0.0.0.0/0 Classless Inter-Domain Routing (CIDR) all'indirizzo IP privato di Firewall di Azure. Specificare l'appliance virtuale per il tipo di hop successivo.

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

Per ulteriori informazioni consulta:

Distribuire i carichi di lavoro in un cluster AKS privato quando si usa Azure DevOps

Se si usa Azure DevOps, non è possibile usare agenti ospitati Azure DevOps Microsoft per distribuire i carichi di lavoro in un cluster del servizio Azure Kubernetes privato perché non hanno accesso al server API. Per distribuire carichi di lavoro nel tuo cluster AKS privato, è necessario effettuare il provisioning e usare un agente self-hosted di Azure DevOps nella stessa rete virtuale del tuo cluster AKS privato o in una rete virtuale connessa tramite peering. Nel secondo caso, 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 usare un set di scalabilità di macchine virtuali Azure. Per ulteriori informazioni, vedere agenti del set di scalabilità di macchine virtuali. 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 ulteriori informazioni consulta:

Se le subnet che ospitano i pool di nodi del cluster AKS privato sono configurate per instradare il traffico in uscita verso Firewall di Azure tramite una tabella di routing e UDR, assicuratevi di creare le regole applicative e di rete appropriate. Queste regole devono consentire all'agente di accedere a siti esterni per scaricare e installare strumenti come Docker, Kubectl, il 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.

In alternativa, è possibile configurare un pool DevOps gestito nella rete virtuale che ospita il cluster del servizio Azure Kubernetes 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. Implementano procedure consigliate per la sicurezza, offrono opzioni per bilanciare i costi e le prestazioni, fornire percorsi per scenari comuni e ridurre significativamente il tempo impiegato per creare e gestire 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 in modo che le pipeline CI/CD possano interagire con il server API Kubernetes del cluster del servizio Azure Kubernetes privato. Questi agenti consentono anche alle pipeline di accedere alle risorse Azure, ad esempio Registro Container, che bloccano l'accesso alla rete pubblica e consentono solo le connessioni tramite un endpoint privato definito nella stessa rete virtuale o in una rete con 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

In questo scenario, un carico di lavoro in esecuzione in AKS viene esposto tramite un load balancer pubblico di Azure (un servizio Kubernetes LoadBalancer) nel gruppo di risorse dei nodi del cluster. Firewall di Azure si trova davanti al servizio di bilanciamento del carico e usa un indirizzo IP pubblico dedicato e una regola DNAT per convertire il traffico in ingresso all'indirizzo IP pubblico e alla porta del servizio di bilanciamento del carico. Questo modello centralizza l'ispezione in ingresso, il DNAT e il filtraggio basato sull'intelligence delle minacce sul firewall e consente ad AKS di continuare a gestire il bilanciatore del carico per il servizio Kubernetes. Usare questo approccio quando il carico di lavoro deve essere raggiungibile da Internet, ma si vuole che tutto il traffico in ingresso attraversi il firewall hub prima che raggiunga il cluster.

Questo diagramma mostra la topologia di rete dello scenario.

Ecco il flusso del messaggio:

Una richiesta all'applicazione web ospitata in AKS viene inviata a un indirizzo IP pubblico che Firewall di Azure espone tramite una configurazione di indirizzo IP pubblico. Sia l'indirizzo IP pubblico che la configurazione dell'indirizzo IP pubblico sono dedicati a questo carico di lavoro.
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 usati dal carico di lavoro nel bilanciatore del carico pubblico del cluster AKS nel gruppo di risorse del nodo.
Il servizio di bilanciamento del carico invia la richiesta a un pod del servizio Kubernetes eseguito in un nodo agente nel cluster del servizio Azure Kubernetes.
Il messaggio di risposta viene rinviato al chiamante originale tramite un UDR. La route imposta l'indirizzo IP pubblico di Firewall di Azure come prefisso di indirizzo e Internet come tipo hop successivo.
Qualsiasi chiamata in uscita avviata dal carico di lavoro viene instradata all'indirizzo IP privato del Firewall di Azure dalla route definita dall'utente predefinita. La route utilizza 0.0.0.0/0 come prefisso dell'indirizzo e l'appliance virtuale come tipo di hop successivo.

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

In questo contesto, un'applicazione ASP.NET Core è ospitata come servizio da un cluster AKS ed è posta davanti a un controller Ingress esposto da un bilanciatore del carico interno. Gli approcci consigliati per l'ingress in AKS sono l'implementazione della Gateway API per l'instradamento delle applicazioni o Application Gateway for Containers. L'implementazione della Gateway API per il routing delle applicazioni usa lo standard Kubernetes Gateway API con un piano di controllo basato su Istio per la gestione del traffico in entrata nel cluster. Application Gateway for Containers è un bilanciatore del carico di livello 7, completamente gestito e nativo di Azure, che supporta anche Gateway API e offre gestione avanzata del traffico, terminazione TLS e hosting multisito all'esterno del cluster. Entrambe le opzioni supportano la configurazione di un servizio di bilanciamento del carico interno con un indirizzo IP privato nella rete virtuale spoke che ospita il cluster del servizio Azure Kubernetes. Quando si distribuisce un controller di ingresso 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 chiamato 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, Firewall di Azure espone l'applicazione Web di test usando un indirizzo IP pubblico dedicato Azure.

Ecco il flusso del messaggio:

Una richiesta per l'applicazione Web di test ospitata in AKS viene inviata a un indirizzo IP pubblico che Firewall di Azure espone tramite una configurazione IP pubblica. Sia l'indirizzo IP pubblico che la configurazione dell'indirizzo IP pubblico sono dedicati a questo carico di lavoro.
Una regola DNAT di Firewall di Azure traduce l'indirizzo IP pubblico e la porta di Firewall di Azure nell'indirizzo IP privato e nella porta usati dal controller di ingresso o gateway selezionato nel bilanciatore del carico interno del cluster AKS nel gruppo di risorse dei nodi.
Il bilanciatore del carico interno invia la richiesta a uno dei pod di un servizio Kubernetes in esecuzione su un nodo agente nel cluster AKS.
Il messaggio di risposta ritorna al chiamante originale attraverso una UDR. La route utilizza 0.0.0.0/0 come prefisso dell'indirizzo e l'appliance virtuale come tipo di hop successivo.
Qualsiasi chiamata in uscita avviata dal carico di lavoro viene instradata dalla UDR all'indirizzo IP privato di Firewall di Azure.

Considerazioni

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

Alcune delle considerazioni seguenti sono raccomandazioni generali, piuttosto che indicazioni specifiche di Firewall di Azure per la protezione di un cluster AKS. Questi elementi sono considerati requisiti essenziali della soluzione. Queste linee guida si applicano alle considerazioni relative a sicurezza, prestazioni, disponibilità e affidabilità, archiviazione, mesh di servizi e monitoraggio.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Considera i metodi seguenti per ottimizzare la disponibilità del tuo cluster AKS e dei carichi di lavoro.

Resilienza intraregion

Durante la distribuzione, è possibile configurare il Firewall di Azure per coprire più zone di disponibilità per una maggiore disponibilità. Per le percentuali di disponibilità, vedere il contratto sul livello di servizio (SLA) di Firewall di Azure in Contratti sul livello di servizio per i servizi online Microsoft. È anche possibile associare Firewall di Azure a una zona specifica per la prossimità. Tuttavia, questa configurazione influisce sul contratto di servizio. Non si applica alcun costo aggiuntivo 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 della zona nel Registro Contenitori per la resilienza e la disponibilità elevata.
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.
Valutare l'uso del livello tariffario Standard o Premium per i cluster AKS che ospitano carichi di lavoro critici. Questi livelli includono uno SLA sul tempo di attività del cluster con garanzia finanziaria. Il livello Standard garantisce la disponibilità di 99.95% dell'endpoint del server API Kubernetes per i cluster che usano zone di disponibilità o 99.9% per i cluster che non usano zone di disponibilità. Il livello Premium offre le stesse garanzie di contratto di servizio con supporto a lungo termine aggiuntivo (LTS) per le versioni di Kubernetes. Per altre informazioni, vedi livelli tariffari di AKS. AKS usa repliche del piano di controllo distribuite tra domini di aggiornamento e domini di errore per garantire che i requisiti del contratto di servizio (SLA) siano soddisfatti.
Valuta l'uso di AKS Automatic SKU per i nuovi cluster che possono beneficiare di un'esperienza di gestione dei nodi interamente gestita, con procedure consigliate integrate per affidabilità, sicurezza e prestazioni. AKS Automatic usa il livello tariffario Standard per impostazione predefinita.

Continuità aziendale e ripristino di emergenza

È consigliabile distribuire la soluzione in almeno due aree di Azure abbinate 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 (BC/DR).
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 Gestione firewall di Azure panoramica dei criteri.
Crea script, documenta e testa regolarmente il processo di failover regionale in un ambiente di QA. Questo test consente di evitare problemi imprevedibili se un'interruzione influisce su un servizio principale nell'area primaria. Questi test verificano anche se la strategia di disaster recovery soddisfa gli obiettivi RPO e RTO, nonché eventuali procedure manuali o interventi degli operatori necessari durante 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 Replica geografica in Registro Contenitori.
Quando una replica regionale si degrada, Container Registry reindirizza automaticamente le richieste pull tramite il relativo endpoint globale (<registry>.azurecr.io) a una replica integra. Questo failover si verifica internamente entro pochi minuti e non richiede modifiche alla configurazione del servizio Azure Kubernetes o DNS.
Se possibile, evitare di archiviare lo stato del servizio nel contenitore. Usare invece un Azure PaaS che supporta la replica a più aree.
Se si usa Archiviazione, preparare e testare un processo per la migrazione dell'archiviazione dall'area primaria all'area di backup.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

La piattaforma Azure offre protezione da varie minacce, ad esempio intrusioni di rete e attacchi DDoS. Usare un web application firewall (WAF) per proteggere tutte le applicazioni Web e i servizi ospitati dal servizio Azure Kubernetes che espongono un endpoint HTTPS pubblico. È necessario proteggersi da minacce comuni, ad esempio SQL injection, scripting tra siti e altri exploit Web. A questo scopo, usare regole OWASP (Open Web Application Security Project) e regole personalizzate. Web application firewall di Azure offre una protezione centralizzata per le applicazioni Web da exploit e vulnerabilità comuni. È possibile distribuire Web application firewall di Azure 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 rende l'applicazione non disponibile per gli utenti legittimi. Gli attacchi DDoS possono colpire qualsiasi endpoint raggiungibile pubblicamente tramite Internet. Ogni proprietà in Azure include la protezione dell'infrastruttura DDoS di Azure senza costi aggiuntivi. La scala e la capacità complete della rete globalmente distribuita di Azure forniscono una difesa contro gli attacchi comuni a livello di rete tramite il monitoraggio costante del traffico 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.

Protezione DDoS Network 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. Abilitare Protezione di rete DDoS nelle reti virtuali perimetrali.

Altre considerazioni sulla sicurezza includono:

Crea un endpoint privato per qualsiasi servizio PaaS usato dai carichi di lavoro AKS, ad esempio Key Vault, bus di servizio di Azure e database SQL di Azure. Il traffico tra le applicazioni e questi servizi non è esposto alla rete Internet pubblica. Il traffico tra la rete virtuale del cluster AKS e un'istanza di servizio PaaS tramite un endpoint privato transita sulla rete backbone di Microsoft, ma la comunicazione non passa attraverso Firewall di Azure. Questo meccanismo offre una maggiore sicurezza e una migliore protezione contro la perdita di dati. Per altre informazioni, vedere collegamento privato.
Quando si usa Application Gateway davanti al cluster AKS, è consigliabile usare un criterio di Web application firewall per proteggere dagli attacchi i carichi di lavoro esposti pubblicamente che vengono eseguiti in AKS.
Usare i criteri di rete per separare e proteggere le comunicazioni intraservizi. Controllare quali componenti possono comunicare tra loro. Per impostazione predefinita, tutti i pod in Kubernetes possono inviare e ricevere traffico senza limitazioni. Usare Azure CNI con tecnologia Cilium per applicare i criteri di rete. Calico è supportato anche se è necessario per garantire la compatibilità con gli strumenti esistenti. Per altre informazioni, vedere criteri di rete in AKS.
Non esporre la connettività remota ai nodi 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 del Firewall di Azure e nei criteri del firewall. Per altre informazioni sui log del proxy DNS, vedi log e metriche di Firewall di Azure.
È possibile usare Firewall di Azure davanti a un controller di ingresso basato su API gateway per esporre i carichi di lavoro su HTTPS e usare un sottodominio e un certificato separati per ogni applicazione. Le soluzioni di ingress gestite consigliate per AKS sono Application Gateway for Containers e l'implementazione dell'API Gateway per il routing delle applicazioni. Application Gateway for Containers è un servizio di bilanciamento del carico di livello 7, nativo di Azure e completamente gestito, esterno al cluster, che supporta Kubernetes Gateway API e l'hosting multisito. L'implementazione della Gateway API per l'instradamento delle applicazioni usa un piano di controllo basato su Istio per fornire l'instradamento del traffico all'interno del cluster tramite le risorse Kubernetes Gateway e HTTPRoute. Non usare AGIC per le nuove distribuzioni.
È possibile usare Firewall di Azure davanti a un controller di ingresso basato su API gateway per esporre i carichi di lavoro su HTTPS e usare un sottodominio e un certificato separati per ogni applicazione. Le soluzioni gestite consigliate per l'ingresso in AKS sono Application Gateway for Containers e l'implementazione Gateway API per il routing delle applicazioni. Application Gateway for Containers è un servizio di bilanciamento del carico di livello 7 completamente gestito, nativo di Azure, esterno al cluster, che supporta la Gateway API di Kubernetes e l'hosting multisito. L'implementazione della Gateway API per il routing delle applicazioni usa un piano di controllo basato su Istio per fornire l'instradamento del traffico all'interno del cluster tramite le risorse Kubernetes Gateway e HTTPRoute. Non usare AGIC per le nuove distribuzioni.
Configurare la terminazione TLS all'ingresso scelto. Per informazioni su TLS con Application Gateway for Containers, vedere TLS policy with Application Gateway for Containers. Per TLS con il routing delle applicazioni, vedere Proteggere l'ingresso usando l'implementazione dell'API del gateway di routing dell'applicazione. In alternativa, è possibile usare cert-manager per generare automaticamente i certificati TLS con Let's Encrypt.
Il coordinamento rigoroso tra l'operatore Firewall di Azure e i team del cluster e del carico di lavoro è necessario per la distribuzione iniziale del cluster e per le operazioni in corso man mano che le esigenze del carico di lavoro e del cluster si evolvono. Questo coordinamento è particolarmente importante quando si configurano i meccanismi di autenticazione, ad esempio OAuth 2.0 e OpenID Connect, che i carichi di lavoro usano per autenticare i client.
Usare le linee guida seguenti per proteggere l'ambiente descritto in questo articolo:

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

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

Livelli di servizio
Scalabilità (il numero di istanze che i servizi allocano dinamicamente per supportare una determinata richiesta)
Script di automazione
Il tuo livello DR

Dopo aver valutato questi dettagli di configurazione, usare il calcolatore dei prezzi di Azure per eseguire una stima dei costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

DevOps

Distribuisci i tuoi carichi di lavoro in AKS tramite un chart Helm in una pipeline CI/CD. Usare un sistema DevOps come GitHub Actions o Azure DevOps. Per ulteriori informazioni, vedere Compilare e distribuire in AKS.
Testare correttamente un'applicazione prima di renderla disponibile agli utenti usando i test A/B e le distribuzioni canary nella gestione del ciclo di vita dell'applicazione. È possibile usare diverse tecniche per suddividere il traffico tra versioni diverse dello stesso servizio. In alternativa, è possibile usare le funzionalità di suddivisione del traffico fornite da un'implementazione della mesh di servizi. Per altre informazioni, vedere Gestione del traffico Istio.
Usare Registro Azure Container o un altro registro contenitori (ad esempio Docker Hub) per archiviare le immagini Docker private distribuite nel cluster. 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.
Decidere quali risorse di Firewall di Azure e di routing sono gestite dalla pipeline IaC dell'infrastruttura e quali risorse sono gestite separatamente dagli operatori di rete o della sicurezza. Se utilizzi Terraform, puoi usare il meta-argomento ciclo di vita con ignore_changes per le risorse Criteri di Firewall di Azure e Tabelle di route di Azure. Questa configurazione consente a Terraform di creare e gestire le risorse, permettendo al contempo di gestire al di fuori di Terraform le regole DNAT, applicative e di rete nei criteri del firewall e le UDR nella tabella di route, senza che vengano ripristinate alla successiva esecuzione di apply. I moduli Terraform di esempio per questo scenario usano questo modello.

Monitoraggio

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

Abilita i log strutturati di Firewall di Azure per una registrazione dettagliata basata su uno schema che semplifica le query e l'analisi. I log strutturati offrono visibilità su modelli di traffico, riscontri delle regole, azioni di intelligence sulle minacce e segnali del sistema di rilevamento e prevenzione delle intrusioni (IDPS) in un formato che si integra con Monitoraggio di Azure Log Analytics, Microsoft Sentinel e strumenti SIEM non Microsoft.
Usa il monitoraggio di Kubernetes in Monitoraggio di Azure 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.

Contributori

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

Autore principale:

Paolo Salvatori | Ingegnere del servizio principale

Altri contributori:

Sam Cogan | Senior Cloud Solution Architect

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

Passo successivo

Guida al servizio Well-Architected Framework per AKS

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-23