Usare Firewall di Azure per proteggere un cluster del 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).
VmSubnet: ospita una macchina virtuale jump box ed endpoint privati
AppGatewaySubnet: ospita Web application firewall v2 del gateway applicazione
AzureBastionSubnet: ospita Azure Bastion

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à:

Driver CSI (Container Storage Interface) per dischi di Azure e File di Azure
Rif: integrazione di Microsoft Entra gestita dal servizio Azure Kubernetes.
Controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes
Identità gestita al posto di un'entità servizio
Criteri di rete di Azure
Informazioni dettagliate sul contenitore di Monitoraggio di Azure
Controller di ingresso del gateway applicazione
Allocazione dinamica di indirizzi IP e supporto di subnet avanzato

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 macchina virtuale viene distribuita nella stessa rete virtuale che ospita il cluster del servizio Azure Kubernetes. Quando si distribuisce il servizio Azure Kubernetes come cluster privato, la macchina virtuale può essere usata dagli amministratori di sistema per gestire il cluster tramite lo strumento della riga di comando Kubernetes. I log di diagnostica di avvio della macchina virtuale vengono archiviati in un account di 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 creare, archiviare e gestire le immagini e gli artefatti dei contenitori, ad esempio i grafici Helm.

Il servizio Azure Kubernetes non offre una soluzione predefinita per proteggere il traffico in ingresso e in 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 e in uscita usando regole DNAT, regole di rete e regole dell'applicazione. Il firewall protegge anche i carichi di lavoro con filtri basati 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 route definite dall'utente instradano il traffico in uscita dal cluster del servizio Azure Kubernetes al Firewall di Azure.

Nota

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

Un Key Vault viene usato come archivio segreto dai carichi di lavoro eseguiti nel servizio Azure Kubernetes per recuperare chiavi, certificati e segreti tramiteMicrosoft Entra Workload ID, Secrets Store CSI DriverDapr. Il collegamento privato di Azure consente ai carichi di lavoro del servizio Azure Kubernetes di accedere ai servizi PaaS di Azure, ad esempio Key Vault, tramite 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 le metriche e i log di diagnostica dai servizi Azure.

Componenti

Firewall di Azure: un servizio di sicurezza firewall di rete intelligente e nativo del cloud, che offre 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 Azure Container è un servizio gestito di registri Docker privato basato sull'applicazione open source Docker Registry 2.0. Usare i registri contenitori di Azure con la pipeline di sviluppo e distribuzione di contenitori esistente oppure usare Attività del Registro Azure Container per compilare immagini di contenitore in Azure.
Il servizio Azure Kubernetes semplifica la distribuzione dei cluster Kubernetes gestito 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. Dal momento che i master Kubernetes sono gestiti da Azure, le attività di gestione e manutenzione riguardano solo i nodi agente.
Azure Key Vault archivia in modo sicuro i segreti e ne controlla l'accesso, ad esempio chiavi API, password, certificati e chiavi crittografiche. Azure Key Vault facilita anche il provisioning, la gestione e la distribuzione dei certificati TLS/SSL (Transport Layer Security/Secure Sockets Layer) pubblici e privati da usare con Azure e con 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 connettività RDP (Remote Desktop Protocol) e SSH (Secure Shell) facile e sicura alle macchine virtuali nella rete virtuale direttamente dal portale di Azure tramite TLS.
Macchine virtuali di Azure offre risorse di calcolo scalabili su richiesta che offrono la flessibilità della virtualizzazione.
Rete virtuale di Azure è il blocco predefinito fondamentale per le reti private di Azure. La rete virtuale consente alle risorse di Azure (come le VM) di comunicare tra loro, con Internet e con le reti locali con maggiore sicurezza. Una rete virtuale di Azure è simile a una rete locale tradizionale, ma include i vantaggi dell'infrastruttura di Azure come scalabilità, disponibilità e isolamento.
Le interfacce di rete virtuale 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.
Azure Managed Disks offre volumi di archiviazione a livello di blocco che vengono gestiti nelle macchine virtuali di Azure. I tipi di dischi per macchine virtuali disponibili sono dischi Ultra, unità SSD Premium, unità SSD Standard e unità disco rigido (HDD) Standard.
Archiviazione BLOB di Azure è 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 Archiviazione BLOB 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

I cluster del servizio Azure Kubernetes vengono 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 del servizio Azure Kubernetes devono accedere a porte specifiche e 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 al nome di dominio completo, al protocollo e alla porta della destinazione, fornendo un controllo del traffico in uscita con granularità fine. Consente anche l'inserimento di domini di dominio completi associati alle dipendenze in uscita di un cluster del servizio Azure Kubernetes, che non è possibile con i gruppi di sicurezza di rete. Inoltre, il filtro basato sull'intelligence per le minacce in 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.

Si può creare un cluster AKS 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 di Firewall di Azure.

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 può limitare il traffico HTTP e HTTPS in uscita in base all'FQDN della destinazione. Configurare le regole di sicurezza e del firewall preferite per consentire le porte e gli indirizzi richiesti. Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster del servizio Azure Kubernetes.

Analogamente, è possibile controllare il traffico in ingresso e migliorare la sicurezza abilitando il filtro basato sull'intelligence per le 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 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 giungono all'indirizzo IP pubblico del firewall, ma tornano al firewall tramite l'indirizzo IP privato (usando la route predefinita). Ciò non costituisce 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 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 l'Applicazione virtuale per Next hop type.

Per altre informazioni, vedere Tutorial: distribuire e configurare Firewall di Azure tramite 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, Azure CLI e Helm nella macchina virtuale dell'agente. Per altre informazioni, vedere Eseguire un agente self-hosted in Docker.

In alternativa, è possibile configurare un pool DevOps gestito (MDP) 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 di 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 del servizio Azure Kubernetes privato e accedere alle risorse di Azure, ad esempio Registro Azure Container, con accesso alla rete pubblica disabilitata e raggiungibile solo 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 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 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 standard 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 tramite un indirizzo IP pubblico di Azure dedicato.

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.
Un Azure Firewall DNAT rule converte l'IP pubblico e la porta di Azure Firewall nell'IP privato e nella porta utilizzati dal controller di ingresso NGINX nel Load Balancer Standard interno del cluster AKS 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 servizio di bilanciamento del carico Standard interno.

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 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, utilità di pianificazione, 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 protezione migliorata contro varie minacce, ad esempio intrusioni nella 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 protezione centralizzata migliorata per le applicazioni Web da exploit e vulnerabilità comuni. È possibile distribuire un Azure WAF con il gateway applicazione di Azure, Frontdoor di Azure o la rete per la distribuzione di 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 è protetta da Protezione DDoS (Basic) dell'infrastruttura 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 di Azure, compresi 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. È consigliabile abilitare Protezione DDOS Network 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, il bus di servizio Azure o il 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 del servizio Azure Kubernetes e un'istanza di un servizio PaaS tramite un endpoint privato sposta la rete backbone Microsoft, ma 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 cos'è Collegamento privato di Azure?.
Quando si usa il gateway applicazione davanti al cluster del servizio Azure Kubernetes, usare un criterio del Web application firewall per proteggere gli carichi di lavoro pubblici eseguiti nel servizio Azure Kubernetes dagli 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 Criteri di rete di Azure o Criteri di rete Calico per definire regole che controllano il flusso del 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 Azure Bastion per instradare il traffico al cluster del servizio Azure Kubernetes.
Prendere in considerazione l'uso di 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 del 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 un filtro FQDN affidabile nelle regole di rete. È possibile abilitare il proxy DNS nelle impostazioni di Firewall di Azure e Criterio firewall. Per altre informazioni sui log proxy DNS, vedere Log e metriche di Firewall di Azure.
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 in ingresso del gateway applicazione (AGIC) configurerà automaticamente il listener del gateway applicazione di Azure per la terminazione SSL (Secure Socket Layer).
È possibile usare Firewall di Azure davanti a un proxy di servizio come il controller di ingresso NGINX. Queste funzionalità includono 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 in ingresso, è possibile usare un singolo indirizzo IP di 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 la multi-tenancy nel servizio Azure Kubernetes. Riteniamo che siano requisiti essenziali di questa soluzione. Prendere in considerazione i metodi seguenti per ottimizzare la disponibilità per il cluster e i carichi di lavoro del servizio Azure Kubernetes.

Resilienza all'interno dell'area

Durante la distribuzione, è possibile configurare il Firewall di Azure per coprire 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à, inclusi i trasferimenti di dati della zona tra disponibilità.
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 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 in Registro Container per usufruire di resilienza all'interno dell'area e 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, ad esempio 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 relativo al tempo di attività è una funzionalità facoltativa che consente di ottenere un contratto di servizio con copertura finanziaria più elevata per un cluster. Questo contratto di servizio garantisce una disponibilità dell'endpoint del server dell'API Kubernetes pari al 99,95% 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.

Ripristino di emergenza e continuità aziendale

È consigliabile distribuire la soluzione in almeno due aree di Azure abbinate all'interno di un'area geografica. È anche consigliabile adottare un servizio di bilanciamento del carico globale, come 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 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 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 di Firewall di Azure Manager.
Creare script, documentare e testare periodicamente i processi di failover a livello di area 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 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 i servizi PaaS di Azure che supportano la replica di tipo multiarea.
Se si usa Archiviazione di Azure, preparare e testare la procedura di 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

Usare un grafico Helm in una pipeline di integrazione continua e recapito continuo (CI/CD) per distribuire i carichi di lavoro nel servizio Azure Kubernetes. 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, 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 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à di 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 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 contenitori e Key Vault) per raccogliere log di diagnostica e 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 livello di ripristino di emergenza

Dopo aver valutato questi dettagli di configurazione, usare il calcolatore dei prezzi di Azure per eseguire una stima dei costi. Per altre opzioni di ottimizzazione dei prezzi, vedere 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 ulteriori informazioni, vedi Creare un progetto 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

Assicurarsi di avere a portata di mano le informazioni sulla sottoscrizione di Azure.

Creare un clone del repository GitHub.

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:

Condividi tramite

Usare Firewall di Azure per proteggere un cluster del servizio Azure Kubernetes