Usare Firewall di Azure per proteggere un cluster servizio Azure Kubernetes (servizio Azure Kubernetes)

Firewall di Azure

Servizio Azure Kubernetes

Collegamento privato di Azure

Rete virtuale di Azure

Azure DevOps

Questa guida descrive come creare un cluster del servizio Azure Kubernetes privato in una topologia di rete hub-spoke usando Terraform e Azure DevOps. Firewall di Azure viene usato per controllare il traffico da e verso il cluster servizio Azure Kubernetes (servizio Azure Kubernetes). Il cluster è ospitato da una o più reti virtuali spoke con peering alla rete virtuale hub.

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

I moduli Terraform vengono usati per distribuire una nuova rete virtuale con quattro subnet che ospitano:

Cluster del servizio Azure Kubernetes (AksSubnet).
Una macchina virtuale jump-box e endpoint privati (VmSubnet).
gateway applicazione WAF2 (AppGatewaySubnet).
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 del servizio Azure Kubernetes è costituito dai pool seguenti:

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 macchina virtuale viene distribuita nella rete virtuale che ospita il cluster del servizio Azure Kubernetes. Quando si distribuisce il servizio Azure Kubernetes come cluster privato, gli amministratori di sistema possono usare questa macchina virtuale per gestire il cluster tramite lo strumento da 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. Registro Azure Container viene usato per compilare, archiviare e gestire immagini e artefatti del contenitore , ad esempio grafici Helm.

L'architettura include un Firewall di Azure usato per controllare il traffico in ingresso e in uscita tramite regole DNAT, regole di rete e regole dell'applicazione. Consente inoltre di proteggere i carichi di lavoro usando il filtro basato su intelligence sulle minacce. I Firewall di Azure e Bastion vengono distribuiti in una rete virtuale hub con peering con la rete virtuale che ospita il cluster del servizio Azure Kubernetes privato. Una tabella di route e le route definite dall'utente vengono usate per instradare il traffico in uscita dal cluster del servizio Azure Kubernetes privato al Firewall di Azure.

Nota

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

Un insieme di credenziali delle chiavi viene usato come archivio segreto da parte dei carichi di lavoro eseguiti nel servizio Azure Kubernetes per recuperare chiavi, certificati e segreti tramite il ID dei carichi di lavoro di Microsoft Entra driver CSI dell'archivio segreti o dapr. collegamento privato di Azure consente ai carichi di lavoro del servizio Azure Kubernetes di accedere ai servizi PaaS di Azure, ad esempio Azure Key Vault, tramite un endpoint privato nella rete virtuale.

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

account Archiviazione BLOB di Azure
Registro Container
Insieme di credenziali delle chiavi di
Server API del cluster Kubernetes

Esiste un collegamento di rete virtuale tra le reti virtuali hub-spoke che ospitano il cluster 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. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. Consente l'ispezione sia del traffico orizzontale destra-sinistra, sia del traffico verticale alto-basso.
Registro Container è un servizio di registro Docker privato gestito basato sul Registro Docker open source 2.0. È possibile usare i registri contenitori di Azure con le pipeline di sviluppo e distribuzione dei contenitori esistenti o usare Attività del Registro Container per compilare immagini del contenitore in Azure.
servizio Azure Kubernetes semplifica la distribuzione di cluster Kubernetes gestiti in Azure tramite l'offload del sovraccarico operativo in Azure. Come servizio Kubernetes ospitato, Azure gestisce attività critiche quali il monitoraggio dell'integrità e la manutenzione. Poiché i master Kubernetes sono gestiti da Azure, è possibile gestire e gestire solo i nodi dell'agente.
Key Vault archivia e controlla l'accesso ai segreti, ad esempio chiavi API, password, certificati e chiavi crittografiche con maggiore sicurezza. Key Vault consente inoltre di effettuare facilmente il provisioning, la gestione e la distribuzione di certificati Transport Layer Security/Secure Sockets Layer (TLS/SSL) pubblici e privati, da usare con Azure e le risorse connesse interne.
Azure Bastion è una soluzione PaaS (piattaforma distribuita come servizio) completamente gestita di cui si effettua il provisioning all'interno della rete virtuale. Azure Bastion offre una migliore connettività RDP (Remote Desktop Protocol) e Secure Shell (SSH) alle macchine virtuali nella rete virtuale, direttamente dalla portale di Azure tramite TLS.
Azure Macchine virtuali offre risorse di calcolo su richiesta e scalabili che offrono la flessibilità della virtualizzazione.
Rete virtuale di Azure è il blocco predefinito 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. Una rete virtuale di Azure è simile a una rete tradizionale locale, ma include vantaggi dell'infrastruttura di Azure, ad esempio scalabilità, disponibilità e isolamento.
Rete virtuale Interfacce consentono alle macchine virtuali di Azure di comunicare con internet, Azure e le risorse locali. È possibile aggiungere diverse schede di interfaccia di rete a una macchina virtuale di Azure, affinché le macchine virtuali figlio possano avere dispositivi di interfaccia di rete e indirizzi IP dedicati.
I dischi gestiti di Azure forniscono volumi di archiviazione a livello di blocco gestiti da Azure nelle macchine virtuali di Azure. Sono disponibili dischi Ultra, unità SSD Premium, UNITÀ SSD standard e unità disco rigido standard (HDD).
La Archiviazione BLOB è una soluzione di archiviazione di oggetti per il cloud. L'archiviazione BLOB è ottimizzata per archiviare enormi quantità di dati non strutturati.
collegamento privato consente di accedere ai servizi PaaS di Azure ,ad esempio BLOB Archiviazione e Key Vault, tramite un endpoint privato nella rete virtuale. È anche possibile usarlo per accedere ai servizi ospitati in Azure di cui si è proprietari o forniti da un partner Microsoft.

Alternative

È possibile usare un firewall di terze parti da Azure Marketplace anziché Firewall di Azure. In tal caso, è responsabilità dell'utente 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

In un ambiente di produzione, le comunicazioni con un cluster Kubernetes devono essere protette da un firewall che monitora e controlla il traffico di rete in ingresso e in uscita in base a un set di regole di sicurezza. Un firewall stabilisce in genere una barriera tra una rete attendibile e una rete non attendibile, ad esempio Internet.

È possibile creare un cluster del servizio Azure Kubernetes privato in una topologia di rete hub-spoke usando Terraform e Azure DevOps. Firewall di Azure viene usato per controllare il traffico da e verso il cluster servizio Azure Kubernetes (servizio Azure Kubernetes). Il cluster è ospitato da una o più reti virtuali spoke con 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 di scalabilità automatica 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 prezzi Firewall di Azure.

Screenshot that shows features of the three Azure Firewall SKUs

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 eseguiti nel cluster del servizio Azure Kubernetes 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 accessibile 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 possibile limitare il traffico HTTP e HTTPS in uscita in base al nome di dominio completo (FQDN) della destinazione. È anche possibile configurare il firewall e le regole di sicurezza per consentire queste porte e indirizzi necessari. Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes.

Analogamente, è possibile controllare il traffico in ingresso e migliorare la sicurezza abilitando il filtro basato sull'intelligence sulle minacce in base a un Firewall di Azure distribuito in una rete perimetrale condivisa. Questo filtro può fornire avvisi e negare il traffico da e verso indirizzi IP dannosi noti e domini.

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 del servizio Azure Kubernetes 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, è necessario configurare il traffico in ingresso verso qualsiasi endpoint pubblico esposto da qualsiasi servizio in esecuzione nel servizio Azure Kubernetes per accedere al sistema tramite 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 che passano all'indirizzo IP pubblico del firewall vengono instradati tramite Internet. Questa configurazione evita la route predefinita all'indirizzo IP privato del firewall.

Per instradare il traffico dei carichi di lavoro del servizio Azure Kubernetes alla 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 Appliance virtuale per il tipo hop successivo.

Per altre informazioni, vedere Esercitazione: Distribuire e configurare Firewall di Azure usando il portale di Azure.

Per altre informazioni, vedi:

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

Se si usa Azure DevOps, tenere presente che non è possibile usare gli agenti ospitati da Microsoft Azure DevOps 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 cluster del servizio Azure Kubernetes privato, è necessario effettuare il provisioning e usare un agente self-hosted di Azure DevOps nella stessa rete virtuale del cluster del servizio Azure Kubernetes privato o in una rete virtuale con peering. Nel secondo caso, assicurarsi di creare un collegamento di rete virtuale tra la zona DNS privata del cluster del servizio Azure Kubernetes nel gruppo di risorse del nodo e la rete virtuale che ospita l'agente self-hosted di Azure DevOps.

È possibile distribuire un singolo agente Di Azure DevOps windows o Linux in una macchina virtuale oppure usare un set di scalabilità di macchine virtuali. Per altre informazioni, vedere Agenti del set di scalabilità di macchine virtuali di 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 Ubuntu (per gli host Linux) con Docker. Distribuirlo come pod con una o più repliche nel cluster del servizio Azure Kubernetes privato. Per altre informazioni, vedi:

Se le subnet che ospitano i pool di nodi del cluster del servizio Azure Kubernetes privato 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 rete e dell'applicazione appropriate. Queste regole devono consentire all'agente di accedere ai 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 altre informazioni, vedere Eseguire un agente self-hosted in Docker e compilare e distribuire l'agente della pipeline di Azure DevOps nel servizio Azure Kubernetes.

Usare Firewall di Azure davanti a un Load Balancer Standard pubblico

Le definizioni delle risorse nei moduli Terraform usano il meta-argomento del ciclo di vita per personalizzare le azioni quando le risorse di Azure vengono modificate all'esterno 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 criteri di Firewall di Azure contiene un blocco del ciclo di vita per impedire a Terraform di aggiornare la risorsa quando viene creata, aggiornata o eliminata una singola regola. Analogamente, la tabella di route di 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 gestire le regole DNAT, applicazione e di rete di un criterio di Firewall di Azure e le route definite dall'utente di una tabella di route di Azure al di fuori del controllo Terraform.

L'esempio associato a questo articolo contiene una pipeline cd di Azure DevOps che illustra come distribuire un carico di lavoro in un cluster del servizio Azure Kubernetes privato usando una pipeline di Azure DevOps eseguita in un agente self-hosted. L'esempio distribuisce l'applicazione Web di gestione del progetto Bitnami redmine usando un grafico Helm pubblico. Questo diagramma mostra la topologia di rete dell'esempio:

Ecco il flusso del messaggio:

Una richiesta per l'applicazione Web ospitata dal servizio Azure Kubernetes 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.
Una regola DNAT Firewall di Azure converte l'indirizzo IP pubblico e la porta Firewall di Azure nell'indirizzo IP pubblico e nella porta usata dal carico di lavoro nel Load Balancer Standard pubblico kubernetes del cluster del servizio Azure Kubernetes nel gruppo di risorse del nodo.
Il servizio di bilanciamento del carico invia la richiesta a uno dei pod del servizio Kubernetes in esecuzione in uno dei nodi agente del cluster del servizio Azure Kubernetes.
Il messaggio di risposta viene inviato al chiamante originale tramite una route definita dall'utente. L'indirizzo IP pubblico Firewall di Azure è il prefisso dell'indirizzo e Internet è il tipo hop successivo.
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 hop successivo.

Per altre informazioni, vedere Usare Firewall di Azure davanti al Load Balancer Standard pubblico del cluster del servizio Azure Kubernetes.

Usare Firewall di Azure davanti a un Load Balancer Standard interno

Nell'esempio associato a questo articolo, un'applicazione ASP.NET Core è ospitata come servizio da un cluster del servizio Azure Kubernetes e front-end da un controller di ingresso NGINX. Il controller di ingresso NGINX viene esposto tramite un servizio di bilanciamento del carico interno con un indirizzo IP privato nella rete virtuale spoke che ospita il cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Creare un controller di ingresso a 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 standard interno denominato kubernetes-internal nel gruppo di risorse del nodo. Per altre informazioni, vedere Usare un servizio di bilanciamento del carico interno con il servizio Azure Kubernetes. Come illustrato nel diagramma seguente, l'applicazione Web di test viene esposta dal Firewall di Azure tramite un indirizzo IP pubblico di Azure dedicato.

Ecco il flusso del messaggio:

Una richiesta per l'applicazione Web di test ospitata dal servizio Azure Kubernetes 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.
Una regola DNAT Firewall di Azure converte l'ip pubblico Firewall di Azure e la porta nell'INDIRIZZO IP privato e nella porta usata dal controller di ingresso NGINX nel Load Balancer Standard interno del cluster del servizio Azure Kubernetes nel gruppo di risorse del nodo.
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 del servizio Azure Kubernetes.
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 hop successivo.
Qualsiasi chiamata in uscita avviata dal carico di lavoro viene instradata all'indirizzo IP privato della route definita dall'utente.

Per altre informazioni, vedere Usare Firewall di Azure davanti a un Load Balancer Standard interno.

Considerazioni

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

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. Questo vale per le considerazioni relative alla sicurezza, alle prestazioni, alla disponibilità e all'affidabilità, all'archiviazione, alla mesh di servizi e al 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 Web ospitate nel 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 app Azure lication Gateway, Frontdoor di Azure e Azure rete per la distribuzione di contenuti.

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 essere mirati a qualsiasi endpoint raggiungibile pubblicamente tramite Internet. Ogni proprietà in Azure include la protezione tramite la protezione dell'infrastruttura DDoS di Azure senza costi aggiuntivi. La scalabilità e la capacità della rete di Azure distribuita a livello globale offre una migliore difesa contro gli 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 di Azure, inclusi i servizi PaaS come DNS di Azure.

Protezione di rete DDoS di Azure, combinata con le procedure consigliate per la progettazione delle applicazioni, offre funzionalità avanzate di mitigazione DDoS per offrire una maggiore difesa dagli attacchi DDoS. È consigliabile abilitare Protezione di rete DDOS di Azure 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 del servizio Azure Kubernetes, 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 del servizio Azure Kubernetes e un'istanza di un servizio PaaS tramite un endpoint privato attraversa la rete backbone Microsoft, ma la comunicazione non passa dal Firewall di Azure. Questo meccanismo offre una migliore sicurezza e una migliore protezione contro la perdita di dati. Per altre informazioni, vedere Che cos'è collegamento privato di Azure?.
Quando si usa gateway applicazione davanti al cluster del servizio Azure Kubernetes, usare criteri web application firewall 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 intraservizie 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 i criteri di rete di Azure o i 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 del servizio Azure Kubernetes. Creare un bastion host, o una jump box, in una rete virtuale di gestione. Usare l'host bastion per instradare il traffico nel cluster del servizio Azure Kubernetes.
È 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 usano intervalli di indirizzi IP autorizzati in un cluster pubblico, consentire tutti gli indirizzi IP in uscita nella raccolta di regole di rete Firewall di Azure. Le operazioni nel cluster usano il server API Kubernetes.
Se si abilita il proxy DNS in Firewall di Azure, Firewall di Azure possibile elaborare e inoltrare query DNS da una o più reti virtuali a un server DNS scelto. Questa funzionalità è fondamentale e necessaria per il filtro FQDN affidabile nelle regole di rete. È possibile abilitare il proxy DNS nelle impostazioni dei criteri di Firewall di Azure e firewall. Per altre informazioni sui log proxy DNS, vedere Firewall di Azure log e metriche.
Quando si usa Firewall di Azure davanti a gateway applicazione, è 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 (AGIC) gateway applicazione configura automaticamente il listener gateway applicazione per la terminazione SSL (Secure Sockets Layer).
È possibile usare Firewall di Azure davanti a un proxy di servizio come il controller di ingresso NGINX. Questo controller fornisce proxy inverso, routing 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 di ingresso e regole di ingresso, è 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 usare 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 Connessione, 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 la multi-tenancy nel servizio Azure Kubernetes. Riteniamo che siano requisiti essenziali per questa soluzione. Considerare i metodi seguenti per ottimizzare la disponibilità del cluster e dei carichi di lavoro del servizio Azure Kubernetes.

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 tempo di attività, vedere il contratto di servizio Firewall di Azure. È 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à. Esistono tuttavia costi aggiuntivi per i trasferimenti di dati in ingresso e in uscita associati alle zone di disponibilità. Per altre informazioni, vedere Dettagli sui prezzi per la larghezza di banda.
Valutare la possibilità di distribuire i pool di nodi del cluster del servizio Azure Kubernetes in tutte le zone di disponibilità in un'area. Usare un Load Balancer Standard di Azure o gateway applicazione davanti ai pool di nodi. Questa topologia offre una migliore resilienza in caso di interruzione di un singolo data center. I nodi del cluster vengono distribuiti in più data center, in tre zone di disponibilità separate all'interno di un'area.
Abilitare la ridondanza della zona in Registro Contenitori per la resilienza all'interno dell'area e la disponibilità elevata.
Usare i vincoli di distribuzione della topologia dei pod per controllare il modo in cui i pod vengono distribuiti nel cluster del servizio Azure Kubernetes tra domini di errore come aree, zone di disponibilità e nodi.
Prendere in considerazione l'uso del contratto di servizio relativo al tempo di attività per i cluster del servizio Azure Kubernetes che ospitano carichi di lavoro cruciali. Il contratto di servizio per il tempo di attività è una funzionalità facoltativa che consente un contratto di servizio con supporto finanziario e superiore per un cluster. Il contratto di servizio per il tempo di attività garantisce la disponibilità elevata dell'endpoint server DELL'API Kubernetes per i cluster che usano zone di disponibilità. È anche possibile usarlo per i cluster che non usano zone di disponibilità, ma il contratto di servizio è inferiore. Per informazioni dettagliate sul contratto di servizio, vedere Contratto di servizio relativo al tempo di attività. Il servizio Azure Kubernetes usa le repliche dei nodi master nei domini di aggiornamento e di errore per garantire che siano soddisfatti i requisiti del contratto di servizio.

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.Use a global load balancer, like Gestione traffico di Azure or Azure Frontdoor, with an active/active/passive routing method, to guarantee business continuity and disaster recovery (DR).
Firewall di Azure è un servizio regionale. 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 questi criteri come criteri 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 da un criterio padre sono sempre classificate in ordine di priorità rispetto alle raccolte di regole di rete definite come parte di un nuovo criterio. La stessa logica si applica alle raccolte di regole dell'applicazione. Tuttavia, le raccolte di regole di rete 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 di Firewall di Azure Manager.
Assicurarsi di creare script, documentare e testare periodicamente qualsiasi processo di failover a livello di area in un ambiente di controllo di qualità. In questo modo è possibile evitare problemi imprevedibili se un servizio principale è interessato da un'interruzione nell'area primaria. Questi test verificano anche se l'approccio di ripristino di emergenza soddisfa le destinazioni RPO/RTO, insieme ai processi manuali e agli interventi necessari per un failover.
Assicurarsi di 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 del servizio Azure Kubernetes. Per altre informazioni, vedere Replica geografica in Registro Azure Container.
Se possibile, evitare di archiviare lo stato del servizio nel contenitore. Usare invece un paaS di Azure che supporta la replica con più aree.
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 nel servizio Azure Kubernetes usando un grafico Helm in una pipeline di integrazione continua e recapito continuo (CI/CD). Usare un sistema DevOps come GitHub Actions o Azure DevOps. Per altre informazioni, vedere Compilare e distribuire nel servizio Azure Kubernetes.
Per testare correttamente un'applicazione prima di renderla disponibile agli utenti, usare i test A/B e le 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 come Docker Hub per archiviare le immagini Docker private che vengono distribuite nel cluster. Il servizio Azure Kubernetes può eseguire l'autenticazione con Registro Azure Container usando la relativa identità Microsoft Entra.
Testare l'ingresso e l'uscita sui carichi di lavoro in un ambiente di pre-produzione 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 Filtro basato sull'intelligence sulle minacce di Firewall di Azure.

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à dei carichi di lavoro e del cluster del servizio Azure Kubernetes.
Configurare tutti i servizi PaaS, ad esempio Registro Container e Key Vault, per raccogliere i log di diagnostica e le metriche.

Ottimizzazione dei costi

Il costo dell'architettura risultante dipende dai dettagli di configurazione seguenti:

Livelli di servizio
Scalabilità (numero di istanze allocate dinamicamente dai servizi per supportare una determinata domanda)
Script di automazione
Il livello di ripristino di emergenza

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

Distribuire lo scenario

Il codice sorgente per questo scenario è disponibile in GitHub. Questa soluzione è open source e viene fornita con una licenza MIT.

Prerequisiti

Per le distribuzioni online, è necessario un account Azure. Se non si ha una sottoscrizione, creare un account di Azure gratuito prima di iniziare. È necessario soddisfare questi requisiti prima di poter distribuire moduli Terraform usando Azure DevOps:

Archiviare il file di stato terraform in un account di archiviazione di Azure. Per altre informazioni sull'uso di un account di archiviazione per archiviare lo stato remoto di Terraform, il blocco dello stato e la crittografia dei dati inattivi, vedere Archiviare lo stato terraform in Archiviazione di Azure.
Creare un progetto Azure DevOps. Per altre informazioni, vedere Creare un progetto in Azure DevOps.
Creare una connessione al servizio Azure DevOps alla sottoscrizione di Azure. È possibile usare l'autenticazione dell'entità servizio (SPA) o un'identità del servizio gestita di Azure quando si crea la connessione al servizio. In entrambi i casi, assicurarsi che all'entità servizio o all'identità gestita usata da Azure DevOps per connettersi alla sottoscrizione di Azure venga assegnato il ruolo di proprietario per l'intera sottoscrizione.

Distribuzione in Azure

Avere a portata di mano le informazioni sulla sottoscrizione di Azure.

Clonare il repository GitHub di workbench:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Seguire le istruzioni riportate nel file README.md.

Collaboratori

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

Autore principale:

Paolo Salvatori | Ingegnere del servizio principale

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

Passaggi successivi

Esaminare le raccomandazioni e le procedure consigliate per il servizio Azure Kubernetes in Microsoft Azure Well-Architected Framework:

Usare Firewall di Azure per proteggere un cluster servizio Azure Kubernetes (servizio Azure Kubernetes)