Controllare il traffico di rete dai pool e cluster di Cluster di HDInsight su AKS
Nota
Azure HDInsight su AKS verrà ritirato il 31 gennaio 2025. Prima del 31 gennaio 2025, sarà necessario eseguire la migrazione dei carichi di lavoro a Microsoft Fabric o a un prodotto Azure equivalente per evitare interruzioni improvvise dei carichi di lavoro. I cluster rimanenti nella sottoscrizione verranno arrestati e rimossi dall’host.
Solo il supporto di base sarà disponibile fino alla data di ritiro.
Importante
Questa funzionalità è attualmente disponibile solo in anteprima. Le Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure includono termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale. Per informazioni su questa anteprima specifica, vedere Informazioni sull'anteprima di Azure HDInsight nel servizio Azure Kubernetes. Per domande o suggerimenti sulle funzionalità, inviare una richiesta in AskHDInsight con i dettagli e seguire Microsoft per altri aggiornamenti nella Community di Azure HDInsight.
HDInsight su AKS è una piattaforma distribuita come servizio (PaaS) gestita in esecuzione nel servizio Azure Kubernetes. HDInsight su AKS consente di distribuire carichi di lavoro open source comuni di Analytics come Apache Spark™, Apache Flink®️ e Trino senza sovraccarico di gestione e monitoraggio dei contenitori.
Per impostazione predefinita, i cluster di HDInsight su AKS consentono connessioni di rete in uscita dai cluster verso qualsiasi destinazione che sia raggiungibile dall'interfaccia di rete del nodo. Ciò significa che le risorse del cluster possono accedere a qualsiasi indirizzo IP pubblico o privato, nome di dominio o URL in Internet o nella rete virtuale.
In alcuni scenari, tuttavia, può essere utile controllare o limitare il traffico in uscita dal cluster per motivi di sicurezza e conformità.
Può, ad esempio, essere necessario:
Impedire ai cluster di accedere a servizi dannosi o indesiderati.
Applicare criteri di rete o regole del firewall al traffico in uscita.
Monitorare o controllare il traffico in uscita dal cluster per la risoluzione dei problemi o per motivi di conformità.
Metodi e strumenti per controllare il traffico in uscita
Sono disponibili diverse opzioni e strumenti per la gestione del flusso del traffico in uscita dai cluster di HDInsight su AKS. È possibile configurarne alcuni a livello di pool di cluster e altri a livello di cluster.
In uscita con bilanciamento del carico. Quando si distribuisce un pool di cluster con questo percorso di uscita, viene effettuato il provisioning di un indirizzo IP pubblico che viene assegnato alla risorsa di bilanciamento del carico. Non è necessario disporre di una rete virtuale (VNET) personalizzata, sebbene sia altamente consigliata. È possibile usare Firewall di Azure o Gruppi di sicurezza di rete (NSG) nella rete virtuale personalizzata per gestire il traffico in uscita dalla rete.
In uscita con routing definito dall'utente. Quando si distribuisce un pool di cluster con questo percorso in uscita, l'utente può gestire il traffico in uscita a livello di subnet tramite Firewall di Azure/gateway NAT e tabelle di route personalizzate. Questa opzione è disponibile solo quando si usa una rete virtuale personalizzata.
Abilitare il servizio Azure Kubernetes privato. Al momento dell’abilitazione del servizio Azure Kubernetes privato nel pool di cluster, al server API del servizio Azure Kubernetes verrà assegnato un indirizzo IP interno e non sarà accessibile pubblicamente. Il traffico di rete tra il server API del servizio Azure Kubernetes e i pool di nodi (cluster) di HDInsight su AKS resterà nella rete privata.
Cluster in ingresso privato. Quando si distribuisce un cluster con l'opzione di ingresso privato abilitata, non verrà creato alcun IP pubblico e il cluster sarà accessibile solo dai client all'interno della stessa rete virtuale. È necessario fornire una soluzione NAT, ad esempio un gateway NAT o un NAT fornito dal firewall, per connettersi alle dipendenze di HDInsight su AKS pubbliche e in uscita.
Nelle sezioni seguenti, viene descritto ogni metodo in dettaglio.
In uscita con bilanciamento del carico
Il bilanciamento del carico viene usato per l'uscita tramite un indirizzo IP pubblico assegnato da HDInsight su AKS. Quando si configura il tipo di bilanciamento del carico in uscita nel pool di cluster, è possibile prevedere l'uscita del bilanciamento del carico creato da HDInsight su AKS.
È possibile configurare l'uscita con bilanciamento del carico tramite il portale di Azure.
Dopo aver scelto questa configurazione, HDInsight su AKS completa automaticamente la creazione di un indirizzo IP pubblico di cui è stato effettuato il provisioning per il traffico in uscita del cluster e lo assegna alla risorsa di bilanciamento del carico.
Un IP pubblico creato da HDInsight su AKS è una risorsa gestita dal servizio Azure Kubernetes, il che significa che tale servizio ne gestisce il ciclo di vita e non richiede un'azione diretta da parte dell’utente a livello della risorsa dell'IP pubblico.
Quando vengono creati i cluster, vengono creati anche alcuni IP pubblici in ingresso.
Per consentire l'invio delle richieste al cluster, è necessario aggiungere all'elenco elementi consentiti. È anche possibile configurare determinate regole nel gruppo di sicurezza di rete per eseguire un controllo con granularità grossolana.
In uscita con routing definito dall'utente
Nota
Il tipo in uscita userDefinedRouting rappresenta uno scenario di rete avanzato e, prima di iniziare, richiede una configurazione di rete appropriata.
Non è supportata la modifica del tipo in uscita dopo la creazione del pool di cluster.
Se è impostato userDefinedRouting, HDInsight su AKS non configura automaticamente i percorsi di uscita. La configurazione in uscita deve essere eseguita dall’utente.
È necessario distribuire il cluster di HDInsight su AKS in una rete virtuale esistente con una subnet configurata in precedenza e stabilire un'uscita esplicita.
Questa architettura richiede che il traffico in uscita sia inviato esplicitamente a un'appliance, come un firewall, un gateway o un proxy, in modo che un indirizzo IP pubblico assegnato al servizio di bilanciamento del carico standard o all'appliance possa gestire Network Address Translation (NAT).
HDInsight su AKS non configura l'indirizzo IP pubblico in uscita o le regole in uscita, a differenza dei cluster del tipo In uscita con bilanciamento del carico, come descritto nella sezione precedente. L‘UDR è l'unica origine per il traffico in uscita.
Per proteggere il traffico in ingresso nel piano di controllo del servizio Azure Kubernetes/server API, è necessario scegliere un cluster privato in base ai requisiti, e selezionare l'opzione di ingresso privato disponibile in ogni forma di cluster per usare il traffico pubblico o interno basato sul bilanciamento del carico.
Creazione del pool di cluster per il traffico in uscita con userDefinedRouting
Quando si usano i pool di cluster di HDInsight su AKS e si sceglie UserDefinedRouting (UDR) come percorso di uscita, non viene effettuato il provisioning del bilanciamento del carico standard. È necessario configurare le regole del firewall per le risorse in uscita prima che userDefinedRouting possa funzionare.
Importante
ll percorso in uscita UDR richiede una route per 0.0.0.0/0 e una destinazione dell'hop successivo del firewall o dell'appliance virtuale di rete nella tabella di route. La tabella di route ha già un valore predefinito 0.0.0.0/0 per Internet. Non è possibile ottenere la connettività Internet in uscita semplicemente aggiungendo questa route, perché Azure necessita di un indirizzo IP pubblico per SNAT. Il servizio Azure Kubernetes controlla che non si crei una route 0.0.0.0/0 che punta a Internet, piuttosto che a un gateway, a un'appliance virtuale di rete e così via. Quando si usa UDR, viene creato un IP pubblico del bilanciamento del carico per le richieste in ingresso solo se si configura un servizio di tipo loadbalancer. HDInsight su AKS non crea mai un indirizzo IP pubblico per le richieste in uscita quando si usa un percorso in uscita UDR.
La procedura seguente illustra come bloccare il traffico in uscita dal servizio HDInsight su AKS alle risorse di Azure back-end o ad altre risorse di rete con Firewall di Azure. Questa configurazione consente di prevenire l'esfiltrazione di dati o il rischio di impianto di programmi dannosi.
Firewall di Azure consente di controllare il traffico in uscita a un livello molto più granulare e di filtrare il traffico in base all'intelligence sulle minacce in tempo reale di Microsoft Cyber Security. È possibile creare, applicare e registrare criteri di connettività di applicazione e di rete in modo centralizzato tra le sottoscrizioni e le reti virtuali.
Di seguito è riportato un esempio di configurazione delle regole del firewall e di test delle connessioni in uscita
Di seguito è riportato un esempio di configurazione delle regole del firewall e di controllo delle connessioni in uscita.
Creare la subnet del firewall richiesta
Per distribuire un firewall nella rete virtuale integrata, è necessaria una subnet denominata AzureFirewallSubnet o Nome di propria scelta.
Nel portale di Azure, passare alla rete virtuale integrata tramite l'app.
Nel riquadro di spostamento a sinistra, selezionare Subnet > + Subnet.
In Nome, immettere AzureFirewallSubnet.
In Intervallo di indirizzi subnet, accettare l'impostazione predefinita o specificare un intervallo di dimensioni pari ad almeno /26.
Seleziona Salva.
Distribuire il firewall e ottenere il relativo protocollo IP
Nel menu del portale di Azure o nella home page selezionare Crea una risorsa.
Digitare firewall nella casella di ricerca e premere INVIO.
Selezionare Firewall, quindi Crea.
Nella pagina Crea un firewall, configurare il firewall come illustrato nella tabella seguente:
Impostazione Valore Gruppo di risorse Stesso gruppo di risorse della rete virtuale integrata. Nome Nome desiderato Paese Stessa area della rete virtuale integrata. Criterio firewall Crearne uno selezionando Aggiungi nuovo. Rete virtuale Selezionare la rete virtuale integrata. Indirizzo IP pubblico Selezionare un indirizzo esistente o crearne uno selezionando Aggiungi nuovo. 
Fare clic su Rivedi e crea.
Selezionare Crea di nuovo. La distribuzione di questo processo richiede alcuni minuti.
Al termine della distribuzione, passare al gruppo di risorse e selezionare il firewall.
Nella pagina Panoramica del firewall, copiare l'indirizzo IP privato. L'indirizzo IP privato verrà usato come indirizzo hop successivo nella regola di routing per la rete virtuale.
Instradare tutto il traffico al firewall
Quando si crea una rete virtuale, Azure crea automaticamente una tabella di route predefinita per ognuna delle relative subnet e aggiunge alla tabella le route predefinite del sistema. In questo passaggio viene creata una tabella di route definita dall'utente che instrada tutto il traffico al firewall e quindi lo associa alla subnet del servizio app nella rete virtuale integrata.
Nel menu del portale di Azure, selezionare Tutti i servizi oppure cercare e selezionare Tutti i servizi in qualsiasi pagina.
In Rete selezionare Tabelle route.
Selezionare Aggiungi.
Configurare la tabella di route come nell'esempio seguente:
Assicurarsi di selezionare la stessa area del firewall creato.
Selezionare Rivedi e crea.
Seleziona Crea.
Al completamento della distribuzione, selezionare Vai alla risorsa.
Nel riquadro di spostamento a sinistra, selezionare Route >Aggiungi.
Configurare la nuova route come illustrato nella tabella seguente:
Impostazione Valore Tipo destinazione Indirizzi IP Indirizzi IP/Intervalli CIDR di destinazione 0.0.0.0/0 Tipo hop successivo Appliance virtuale Indirizzo hop successivo Indirizzo IP privato per il firewall copiato Nel riquadro di spostamento a sinistra, selezionare Subnet >Associa.
In Rete virtuale, selezionare la rete virtuale integrata.
In Subnet, selezionare la subnet di HDInsight su AKS che si vuole usare.
Seleziona OK.
Configurare i criteri firewall
Il traffico in uscita dalla subnet di HDInsight su AKS viene ora instradato al firewall attraverso la rete virtuale integrata. Per controllare il traffico in uscita, aggiungere una regola dell’applicazione al criterio firewall.
Passare alla pagina di panoramica del firewall e selezionare i relativi criteri.
Nel riquadro di spostamento a sinistra della pagina del criterio firewall, aggiungere le regole di rete e dell’applicazione. Ad esempio, selezionare Regole di rete > Aggiungi una raccolta regole.
In Regole, aggiungere una regola di rete con la subnet come indirizzo di origine e specificare una destinazione di FQDN. In modo analogo, aggiungere le regole dell'applicazione.
- È necessario aggiungere le regole del traffico in uscita fornite qui. Fare riferimento a questo documento per l'aggiunta di regole di rete e dell’applicazioneper consentire il traffico necessario per il funzionamento del cluster. L' APIServer del servizio Azure Kubernetes deve essere aggiunto dopo la creazione del clusterPool, poiché è possibile ottenerlo solo dopo aver creato il clusterPool.
- È inoltre possibile aggiungere gli endpoint privati per qualsiasi risorsa dipendente nella stessa subnet, per consentire al cluster di accedervi (ad esempio, l'archiviazione).
Selezionare Aggiungi.
Verificare se viene creato l’IP pubblico
Con le regole del firewall impostate, è possibile selezionare la subnet durante la creazione del pool di cluster.
Dopo aver creato il pool di cluster, è possibile osservare nel gruppo MC che non è stato creato alcun IP pubblico.
Importante
Prima di creare il cluster nella configurazione del pool di cluster con il percorso in uscita Outbound with userDefinedRouting, è necessario assegnare al cluster del servizio Azure Kubernetes, che corrisponde al pool di cluster, il ruolo Network Contributor nelle risorse di rete usate per definire il routing, ad esempio rete virtuale, tabella di route e gruppo di sicurezza di rete (se usato). Altre informazioni su come assegnare il ruolo sono disponibili qui
Nota
Quando si distribuisce un pool di cluster con il percorso in uscita UDR e un cluster in ingresso privato, HDInsight su AKS crea automaticamente una zona DNS privata ed esegue il mapping delle voci per risolvere l’FQDN in modo da accedere al cluster.
Creazione del pool di cluster con il servizio Azure Kubernetes privato
Con il servizio Azure Kubernetes privato, il piano di controllo o il server API dispone di indirizzi IP interni definiti nel documento RFC1918 - Allocazione indirizzi per Internet privato. Tramite questa opzione del servizio Azure Kubernetes privato, è possibile garantire che il traffico di rete tra il server API e i cluster del carico di lavoro di HDInsight su AKS rimanga solo nella rete privata.
Quando si effettua il provisioning di un cluster del servizio Azure Kubernetes privato, il servizio Azure Kubernetes crea per impostazione predefinita un nome di dominio completo privato con una zona DNS privata e un nome di dominio completo pubblico aggiuntivo con un record A corrispondente nel DNS pubblico di Azure. I nodi dell'agente continuano a usare il record nella zona DNS privata per risolvere l'indirizzo IP privato dell'endpoint privato in modo da comunicare con il server API.
HDInsight su AKS invece inserirà automaticamente il record nella zona DNS privata del gruppo gestito creato, in modo da consentire l'ingresso privato.
Cluster con ingresso privato
Il cluster creato con HDInsight su AKS dispone di un FQDN pubblico e di un indirizzo IP a cui chiunque può accedere. Tramite la funzionalità di ingresso privato, è possibile assicurarsi che solo la rete privata possa inviare e ricevere dati tra il client e il cluster di HDInsight su AKS.
Nota
Tramite questa funzionalità, HDInsight su AKS creerà automaticamente record A nella zona DNS privata per l'ingresso.
Questa funzionalità impedisce l'accesso pubblico a Internet al cluster. Il cluster ottiene un bilanciamento del carico interno e un protocollo IP privato. HDInsight su AKS usa la zona DNS privata creata dal pool di cluster per connettere la rete virtuale del cluster ed eseguire la risoluzione dei nomi.
Ogni cluster privato contiene due FQDN: FQDN pubblico e FQDN privato.
FQDN pubblico： {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
L'FQDN pubblico può essere risolto solo in un CNAME con sottodominio; pertanto deve essere usato con il Private DNS zone setting corretto, in modo da assicurarsi che l’FQDN possa essere infine risolto per correggere l'indirizzo IP privato.
La zona DNS privata deve essere in grado di risolvere l’FQDN privato in un protocollo IP (privatelink.{clusterPoolName}.{subscriptionId}).
Nota
HDInsight su AKS crea una zona DNS privata nel pool di cluster nella rete virtuale. Se le applicazioni client si trovano nella stessa rete virtuale, non è necessario configurare nuovamente la zona DNS privata. Nel caso in cui si usi un'applicazione client in una rete virtuale diversa, è necessario utilizzare il peering di rete virtuale per associarsi a una zona DNS privata nella rete virtuale del pool di cluster, oppure gli endpoint privati nella rete virtuale e le zone DNS private, in modo da aggiungere il record A all'IP privato dell'endpoint privato.
FQDN privato： {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
L'FQDN privato verrà assegnato solo ai cluster con l'ingresso privato abilitato. Si tratta di un RECORD-A nella zona DNS privata che si risolve nell'IP privato del cluster.