Controllare il traffico di rete dei cluster AKS e dei pool di cluster proveniente da HDInsight
Importante
Azure HDInsight su Azure Kubernetes Service è stato ritirato il 31 gennaio 2025. Scopri di più su con questo annuncio.
È necessario eseguire la migrazione dei carichi di lavoro a Microsoft Fabric o a un prodotto Azure equivalente per evitare la chiusura brusca dei carichi di lavoro.
Importante
Questa funzionalità è attualmente in anteprima. Le condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure includono termini legali più validi applicabili alle funzionalità di Azure in versione beta, in anteprima o altrimenti non ancora rilasciate nella disponibilità generale. Per informazioni su questa anteprima specifica, vedere informazioni sull'anteprima di Azure HDInsight su AKS. Per domande o suggerimenti sulle funzionalità, inviare una richiesta in AskHDInsight con i dettagli e seguirci per ulteriori aggiornamenti sulla Community di Azure HDInsight.
HDInsight nel servizio Azure Kubernetes è una piattaforma gestita distribuita come servizio (PaaS) in esecuzione nel servizio Azure Kubernetes. HDInsight nel servizio Azure Kubernetes consente di distribuire carichi di lavoro di Open-Source Analytics più diffusi, ad esempio Apache Spark™, Apache Flink®️ e Trino senza sovraccarico di gestione e monitoraggio dei contenitori.
Per impostazione predefinita, HDInsight nei cluster del servizio Azure Kubernetes consente connessioni di rete in uscita da cluster a qualsiasi destinazione, se la destinazione è 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 su Internet o nella rete virtuale.
In alcuni scenari, tuttavia, è possibile controllare o limitare il traffico in uscita dal cluster per motivi di sicurezza e conformità.
Ad esempio, è possibile:
Impedire ai cluster di accedere a servizi dannosi o indesiderati.
Applicare criteri di rete o regole del firewall nel traffico in uscita.
Monitorare o controllare il traffico in uscita dal cluster per la risoluzione dei problemi o la conformità.
Metodi e strumenti per controllare il traffico in uscita
Sono disponibili diverse opzioni e strumenti per gestire come il traffico in uscita fluisce da HDInsight nei cluster AKS. È possibile configurare alcuni di questi 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 in uscita, viene effettuato il provisioning di un indirizzo IP pubblico e assegnato alla risorsa di bilanciamento del carico. Non è necessaria una rete virtuale personalizzata; Tuttavia, è altamente consigliato. È possibile usare Firewall di Azure o gruppi di sicurezza di rete (NSG) nella rete virtuale personalizzata per gestire il traffico che lascia la 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 usando 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. Quando si abilita il 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 HDInsight nei pool di nodi del servizio Azure Kubernetes (cluster) rimarrà nella rete privata.
Cluster di ingresso senza accesso pubblico. Quando si distribuisce un cluster con l'opzione di ingresso privato abilitata, non verrà creato alcun indirizzo IP pubblico e il cluster sarà accessibile solo dai client all'interno della stessa rete virtuale. Per connettersi alle dipendenze in uscita pubbliche di HDInsight su AKS, è necessario fornire la propria soluzione NAT, come un gateway NAT o un NAT fornito dal firewall.
Nelle sezioni seguenti viene descritto in dettaglio ogni metodo.
In uscita con bilanciatore del carico
Il servizio di bilanciamento del carico viene utilizzato per l'egresso attraverso un indirizzo IP pubblico assegnato da HDInsight su AKS (Azure Kubernetes Service). Quando si configura il tipo di bilanciamento del carico in uscita nel pool del cluster, è possibile prevedere traffico in uscita dal bilanciatore di carico creato da HDInsight su AKS (Azure Kubernetes Service).
È possibile configurare la configurazione in uscita con il servizio di bilanciamento del carico usando il portale di Azure.
Dopo aver scelto questa configurazione, HDInsight su AKS completa automaticamente la creazione di un indirizzo IP pubblico, fornito per l'uscita del cluster, che & assegna alla risorsa di bilanciamento del carico.
Un indirizzo IP pubblico creato da HDInsight nel servizio Azure Kubernetes ed è una risorsa gestita dal servizio Azure Kubernetes, il che significa che il servizio Azure Kubernetes gestisce il ciclo di vita di tale indirizzo IP pubblico e non richiede un'azione dell'utente direttamente sulla risorsa IP pubblica.
Quando vengono creati cluster, vengono creati anche determinati indirizzi IP pubblici in ingresso.
Per consentire l'invio delle richieste al cluster, è necessario inserire nella lista consentita il traffico. È anche possibile configurare determinate regole di nel gruppo di sicurezza di rete per eseguire un controllo con granularità grossolana.
In uscita con routing definito dall'utente
Nota
Il tipo di uscita userDefinedRouting
è uno scenario di rete avanzato e richiede una corretta configurazione di rete, prima di iniziare.
La modifica del tipo in uscita dopo la creazione del pool di cluster non è supportata.
Se userDefinedRouting è impostato, HDInsight su AKS non configurerà automaticamente i percorsi in uscita. La configurazione d'uscita deve essere effettuata dall'utente.
È necessario distribuire HDInsight su AKS in un cluster all'interno di una rete virtuale esistente con una subnet configurata in precedenza ed è necessario stabilire un egress esplicito.
Questa architettura richiede l'invio esplicito del traffico in uscita a un'appliance, ad esempio 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 nat (Network Address Translation).
HDInsight su AKS non configura l'indirizzo IP pubblico in uscita o le regole in uscita, a differenza dei cluster di tipo 'Outbound con bilanciamento del carico', come descritto nella sezione precedente. Le route definite dall'utente (UDR) sono l'unica fonte per il traffico in uscita.
Per il traffico in ingresso, è necessario scegliere in base ai requisiti per scegliere un cluster privato (per proteggere il traffico nel piano di controllo del servizio Azure Kubernetes/nel server API) e selezionare l'opzione di ingresso privato disponibile in ogni forma del 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 utilizza HDInsight nei pool di cluster di 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 di poter funzionare userDefinedRouting
.
Importante
Il percorso di uscita dell'UDR richiede una route per 0.0.0.0/0 e come destinazione del prossimo hop il tuo firewall o dispositivo virtuale di rete nella tabella di routing. La tabella di route ha già un valore predefinito 0.0.0.0/0 su Internet. Non è possibile ottenere la connettività Internet in uscita semplicemente aggiungendo questa route, perché Azure necessita di un indirizzo IP pubblico per SNAT. AKS verifica che non si crei una route 0.0.0.0/0 che punta a Internet, ma a un gateway, a un'appliance virtuale di rete (NVA) o simili. Quando si utilizza una route definita dall'utente (UDR), viene creato un indirizzo IP pubblico per il bilanciamento del carico per le richieste in ingresso solo se si configura un servizio del tipo loadbalancer. HDInsight su AKS non crea mai un indirizzo IP pubblico per le richieste in uscita quando si utilizza un percorso di uscita UDR.
Per comprendere come limitare il traffico in uscita dal servizio HDInsight su AKS verso le risorse back-end di Azure o altre risorse di rete, segui la procedura seguente utilizzando Azure Firewall. Questa configurazione consente di evitare l'esfiltrazione dei dati o il rischio di impianto dannoso del programma.
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 centralmente i criteri di connettività di applicazione e rete tra sottoscrizioni e reti virtuali.
Di seguito è riportato un esempio di configurazione delle regole del firewall e del test delle connessioni in uscita
Ecco un esempio di come configurare le regole del firewall e controllare le connessioni in uscita.
Creare la subnet necessaria del firewall
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 con l'app.
Nel pannello di navigazione a sinistra, selezionare Subnet > + Subnet.
Nel campo nome , digitare AzureFirewallSubnet.
intervallo di indirizzi subnet, Accettare l'impostazione predefinita o specificare un intervallo di almeno /26.
Selezionare Salva.
Distribuire il firewall e ottenere il relativo INDIRIZZO IP
Nel menu del portale di Azure o nella pagina home selezionare Crea una risorsa.
Digitare firewall nella casella di ricerca e premere INVIO.
Selezionare Firewall e quindi selezionare Crea.
Nella pagina Creare 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 della scelta Regione Stessa area della rete virtuale integrata. Criteri 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. Questo processo richiede alcuni minuti per essere distribuito.
Al termine della distribuzione, passare al gruppo di risorse e selezionare il firewall.
Copia l'indirizzo IP privato nella pagina panoramica del firewall . 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 route predefinite alla tabella. In questo passaggio viene creata una tabella di route definita dall'utente che instrada tutto il traffico al firewall e quindi la si associa alla subnet del servizio app nella rete virtuale integrata.
Nel menu del portale di Azure selezionare Tutti i servizi o cercare e selezionare Tutti i servizi da qualsiasi pagina.
In Reteselezionare Tabelle di 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.
Selezionare Crea.
Al termine della distribuzione, selezionare Vai alla risorsa.
Nel riquadro di spostamento a sinistra selezionare Percorsi > Aggiungi.
Configurare la nuova route come illustrato nella tabella seguente:
Impostazione Valore Tipo di destinazione Indirizzi IP Indirizzi IP di destinazione/intervalli CIDR 0.0.0.0/0 Tipo di passaggio successivo Appliance virtuale Indirizzo del prossimo nodo Indirizzo IP privato per il firewall copiato Nella barra di navigazione a sinistra, selezionare Subnets, > Associa,.
In Rete virtuale, seleziona la tua rete virtuale integrata.
In Subnet, seleziona la subnet HDInsight su AKS che desideri utilizzare.
Selezionare OK.
Configurare le politiche del firewall
Il traffico in uscita dalla subnet di HDInsight su AKS viene ora instradato attraverso la rete virtuale integrata fino al firewall. Per controllare il traffico in uscita, aggiungere una regola dell'applicazione ai criteri del firewall.
Passare alla pagina di panoramica del firewall e selezionarne i criteri.
Nella pagina dei criteri del firewall, dalla barra di navigazione sinistra, aggiungi regole di rete e di applicazione. Ad esempio, selezionare Regole di rete > Aggiungere una raccolta regole.
In Rulesaggiungere una regola di rete con la subnet come indirizzo di origine e specificare una destinazione FQDN. Analogamente, aggiungere le regole dell'applicazione.
- È necessario aggiungere le regole di traffico in uscita fornite qui. Fare riferimento a questo documento per aggiungere regole di applicazione e di rete per consentire al cluster di funzionare. È necessario aggiungere ApiServer del servizio Azure Kubernetes dopo la creazione del clusterPool perché è possibile ottenere solo apiserver del servizio Azure Kubernetes dopo aver creato il clusterPool.
- È anche possibile aggiungere gli endpoint privati per qualsiasi risorsa dipendente nella stessa subnet affinché il cluster possa accedervi (ad esempio, archiviazione).
Selezionare Aggiungi.
Verificare se viene creato un indirizzo 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 indirizzo IP pubblico.
Importante
Prima di creare il cluster nella configurazione del pool di cluster con Outbound with userDefinedRouting
percorso in uscita, è necessario assegnare al cluster AKS, che corrisponde al pool di cluster, il ruolo Network Contributor
sulle risorse di rete usate per definire il routing, come Virtual Network, Route table e NSG (se usato). Altre informazioni su come assegnare il ruolo qui
Nota
Quando si distribuisce un pool di cluster con percorso di uscita UDR e un cluster di ingresso privato, HDInsight su AKS creerà automaticamente una zona DNS privata ed eseguirà la mappatura delle voci per risolvere il nome di dominio completo per l'accesso al cluster.
Creazione del pool di cluster con AKS privato
Con AKS privato, il piano di controllo o il server API dispone di indirizzi IP interni definiti nel documento RFC1918 - Allocazione degli indirizzi per Internet privato. Usando 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 HDInsight nel servizio Azure Kubernetes 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 FQDN privato con una zona DNS privata e un FQDN pubblico aggiuntivo con un record A corrispondente nel DNS pubblico di Azure. I nodi agente continuano a usare il record nella zona DNS privata per risolvere l'indirizzo IP privato dell'endpoint privato per la comunicazione con il server API.
Poiché HDInsight su AKS inserirà automaticamente il record nella zona DNS privata nel gruppo gestito creato da HDInsight su AKS, per l'ingresso privato.
Cluster con ingresso privato
Quando si crea un cluster con HDInsight nel servizio Azure Kubernetes, ha un nome di dominio completo pubblico e un indirizzo IP a cui chiunque può accedere. Con la funzionalità di ingresso privato, è possibile assicurarsi che solo la rete privata possa inviare e ricevere dati tra il client e l'HDInsight sul cluster Azure Kubernetes Service (AKS).
Nota
Con questa funzionalità, HDInsight nel servizio Azure Kubernetes creerà automaticamente record A nella zona DNS privata per l'ingresso.
Questa funzionalità impedisce l'accesso a Internet pubblico al cluster. Il cluster ottiene un servizio di bilanciamento del carico interno e un indirizzo IP privato. HDInsight su AKS utilizza la zona DNS privata creata dal pool di cluster per connettere la Virtual Network 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
Il nome di dominio completo pubblico può essere risolto solo in un CNAME con sottodominio, pertanto deve essere usato con il Private DNS zone setting
corretto per assicurarsi che il nome di dominio completo possa essere infine risolto per correggere l'indirizzo IP privato.
La zona DNS privata deve essere in grado di risolvere il nome di dominio completo privato in un indirizzo IP (privatelink.{clusterPoolName}.{subscriptionId})
.
Nota
HDInsight nel servizio Azure Kubernetes 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 utilizzi un'applicazione client in una rete virtuale diversa, è necessario utilizzare il peering di rete virtuale e collegarsi alla zona DNS privata nella rete virtuale del pool di cluster, oppure utilizzare endpoint privati nella rete virtuale e zone DNS private, per aggiungere il record A all'indirizzo IP privato dell'endpoint privato.
FQDN privato: {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
Il nome di dominio completo privato verrà assegnato ai cluster solo con l'ingresso privato abilitato. Si tratta di un record A nella zona DNS privata che si risolve nell'INDIRIZZO IP privato del cluster.