Controle o tráfego de rede do HDInsight em pools e clusters do AKS Cluster
Importante
O Azure HDInsight no AKS foi desativado em 31 de janeiro de 2025. Saiba mais com este anúncio.
Você precisa migrar suas cargas de trabalho para Microsoft Fabric ou um produto equivalente do Azure para evitar o encerramento abrupto de suas cargas de trabalho.
Importante
Esta funcionalidade está atualmente em pré-visualização. Os Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure incluem mais termos legais que se aplicam a funcionalidades do Azure que estão em versão beta, em pré-visualização ou ainda não disponibilizadas para disponibilização geral. Para obter informações sobre esta visualização específica, consulte Informações de pré-visualização do Azure HDInsight no AKS. Para perguntas ou sugestões de funcionalidades, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para obter mais atualizações na Comunidade do Azure HDInsight .
O HDInsight no AKS é uma plataforma gerenciada como serviço (PaaS) que é executada no Serviço Kubernetes do Azure (AKS). O HDInsight no AKS permite implantar cargas de trabalho populares do Open-Source Analytics, como Apache Spark™, Apache Flink®️ e Trino, sem a sobrecarga de gerenciar e monitorar contêineres.
Por padrão, o HDInsight em clusters AKS permite conexões de rede de saída de clusters para qualquer destino, se o destino for acessível a partir da interface de rede do nó. Isso significa que os recursos de cluster podem acessar qualquer endereço IP público ou privado, nome de domínio ou URL na Internet ou em sua rede virtual.
No entanto, em alguns cenários, talvez você queira controlar ou restringir o tráfego de saída do cluster por motivos de segurança e conformidade.
Por exemplo, você pode querer:
Impeça que clusters acessem serviços mal-intencionados ou indesejados.
Aplique políticas de rede ou regras de firewall no tráfego de saída.
Monitore ou audite o tráfego de saída do cluster para fins de solução de problemas ou conformidade.
Métodos e ferramentas para controlar o tráfego de saída
Você tem várias opções e ferramentas para gerir o fluxo do tráfego de saída do HDInsight em clusters AKS. Você pode configurar alguns deles no nível do pool de clusters e outros no nível do cluster.
Saída com balanceador de carga. Quando você implanta um pool de clusters com esse caminho de saída, um endereço IP público é provisionado e atribuído ao recurso do balanceador de carga. Uma rede virtual personalizada (VNET) não é necessária; no entanto, é altamente recomendado. Você pode usar o Firewall do Azure ou NSGs (Grupos de Segurança de Rede) na VNET personalizada para gerenciar o tráfego que sai da rede.
Saída com roteamento definido pelo usuário. Quando você implanta um pool de clusters com esse caminho de saída, o usuário pode gerenciar o tráfego de saída no nível da sub-rede usando o Firewall do Azure/Gateway NAT e tabelas de rotas personalizadas. Esta opção só está disponível ao usar uma VNET personalizada.
Habilite o AKS Privado. Quando ativar o AKS privado no seu pool de clusters, será atribuído ao servidor API do AKS um endereço IP interno e não estará acessível publicamente. O tráfego de rede entre o servidor de API do AKS e o HDInsight nos pools de nós do AKS manter-se-á na rede privada.
Cluster de entrada privado. Quando você implanta um cluster com a opção de entrada privada habilitada, nenhum IP público será criado e o cluster só será acessível a partir de clientes dentro da mesma VNET. Você deve fornecer a sua própria solução de NAT, como um gateway NAT ou um NAT disponibilizado pelo seu firewall, para se conectar às dependências públicas de saída do HDInsight no AKS.
Nas seções a seguir, descrevemos cada método em detalhes.
Saída com balanceador de carga
O balanceador de carga é usado para saída por meio de um HDInsight no IP público atribuído ao AKS. Ao configurar o tipo de balanceador de carga de saída no pool de clusters, você pode esperar uma saída do balanceador de carga criado pelo HDInsight no AKS.
Você pode configurar o tráfego de saída com a configuração do balanceador de carga usando o portal do Azure.
Depois de optar por esta configuração, o HDInsight no AKS conclui automaticamente a criação de um endereço IP público provisionado para a saída do cluster, o qual o & atribui ao recurso do balanceador de carga.
Um IP público criado pelo HDInsight no AKS, e é um recurso gerenciado pelo AKS, o que significa que o AKS gerencia o ciclo de vida desse IP público e não requer ação do usuário diretamente no recurso IP público.
Quando clusters são criados, certos IPs públicos de entrada também são criados.
Para permitir que as solicitações sejam enviadas para o cluster, você precisa lista de permissões do tráfego. Você também pode configurar certas regras de no NSG para fazer um controle granular.
Saída com roteamento definido pelo usuário
Observação
O tipo de saída userDefinedRouting é um cenário de rede avançado e requer configuração de rede adequada antes de iniciar.
Não há suporte para alterar o tipo de saída após a criação do pool de clusters.
Se userDefinedRouting estiver definido, o HDInsight no AKS não configurará automaticamente os caminhos de saída. A configuração da saída deve ser feita pelo usuário.
Você deve implantar o HDInsight no cluster AKS em uma rede virtual existente com uma sub-rede que tenha sido configurada anteriormente e deve estabelecer uma saída explícita.
Essa arquitetura requer o envio explícito de tráfego de saída para um dispositivo como firewall, gateway ou proxy, para que um IP público atribuído ao balanceador de carga ou dispositivo padrão possa lidar com a NAT (Network Address Translation).
O HDInsight no AKS não configura o endereço IP público de saída ou as regras de saída, ao contrário dos clusters do tipo Saída com balanceador de carga, conforme descrito na seção acima. Seu UDR é a única fonte de tráfego de saída.
Para o tráfego de entrada, é necessário escolher com base nos requisitos para escolher um cluster privado (para proteger o tráfego no plano de controle AKS/servidor API) e selecionar a opção de entrada privada disponível em cada forma de cluster para usar o tráfego público ou interno baseado no balanceador de carga.
Criação de pool de clusters para saída com userDefinedRouting
Quando você usa o HDInsight em pools de clusters AKS e escolhe userDefinedRouting (UDR) como o caminho de saída, não há nenhum balanceador de carga padrão provisionado. Você precisa configurar as regras de firewall para os recursos de saída antes que userDefinedRouting possa funcionar.
Importante
O caminho de saída UDR precisa de uma rota para 0.0.0.0/0 e um destino de próximo salto do seu Firewall ou NVA na tabela de rotas. A tabela de rotas já tem um padrão 0.0.0.0/0 para a Internet. Você não pode obter conectividade de saída com a Internet apenas adicionando essa rota, porque o Azure precisa de um endereço IP público para SNAT. O AKS verifica se você não cria uma rota 0.0.0.0/0 apontando para a Internet, mas para um gateway, NVA, etc. Quando você usa UDR, um endereço IP público do balanceador de carga para solicitações de entrada só é criado se você configurar um serviço do tipo loadbalancer. O HDInsight no AKS nunca cria um endereço IP público para solicitações de saída quando você usa um caminho de saída UDR.
Com as etapas a seguir, você entenderá como bloquear o tráfego de saída do seu serviço HDInsight no AKS para recursos back-end do Azure ou outros recursos de rede com o Firewall do Azure. Essa configuração ajuda a evitar a exfiltração de dados ou o risco de implantação de programas mal-intencionados.
O Firewall do Azure permite controlar o tráfego de saída em um nível muito mais granular e filtrar o tráfego com base na inteligência de ameaças em tempo real da Microsoft Cyber Security. Você pode criar, impor e registrar centralmente políticas de conectividade de aplicativos e redes em assinaturas e redes virtuais.
Segue-se um exemplo de configuração de regras de firewall e teste das suas ligações de saída
Aqui está um exemplo de como configurar regras de firewall e verificar suas conexões de saída.
Criar a sub-rede de firewall necessária
Para implantar um firewall na rede virtual integrada, você precisa de uma sub-rede chamada AzureFirewallSubnet ou Nome de sua escolha.
No portal do Azure, navegue até a rede virtual integrada ao seu aplicativo.
Na navegação à esquerda, selecione Sub-redes > + Sub-rede.
Em Nome, digite AzureFirewallSubnet.
Intervalo de endereços de sub-rede, aceite o padrão ou especifique um intervalo que seja pelo menos /26 em tamanho.
Selecione Salvar.
Implante o firewall e obtenha seu IP
No menu do portal do Azure ou na página Home, selecione Criar um recurso.
Digite firewall na caixa de pesquisa e pressione Enter.
Selecione Firewall e, em seguida, selecione Criar.
Na página Criar um Firewall, configure o firewall conforme mostrado na tabela seguinte:
Cenário Valor Grupo de recursos Mesmo grupo de recursos que a rede virtual integrada. Nome Nome da sua escolha Região Mesma região da rede virtual integrada. Política de firewall Crie um selecionando Adicionar novo. Rede virtual Selecione a rede virtual integrada. Endereço IP público Selecione um endereço existente ou crie um selecionando Adicionar novo. 
Clique Revisar + criar.
Selecione Criar novamente. Esse processo leva alguns minutos para ser implantado.
Após a conclusão da implantação, vá para o grupo de recursos e selecione o firewall.
Na página de Visão geral do firewall, copie o endereço IP privado. O endereço IP privado será usado como endereço de salto seguinte na regra de roteamento para a rede virtual.
Encaminhar todo o tráfego para o firewall
Quando você cria uma rede virtual, o Azure cria automaticamente uma tabela de rotas padrão para cada uma de suas sub-redes e adiciona rotas padrão do sistema à tabela. Nesta etapa, você cria uma tabela de rotas definida pelo usuário que roteia todo o tráfego para o firewall e a associa à sub-rede do Serviço de Aplicativo na rede virtual integrada.
No menu do portal do Azure, selecione Todos os serviços ou pesquise e selecione Todos os serviços em qualquer página.
Na secção Networking, selecione Tabelas de rotas.
Selecione Adicionar.
Configure a tabela de rotas como o exemplo a seguir:
Certifique-se de selecionar a mesma região do firewall que você criou.
Selecione Rever + criar.
Selecione Criar.
Depois de concluída a implantação, selecione Ir para o recurso.
Na navegação à esquerda, selecione Rotas > Adicionar.
Configure a nova rota conforme mostrado na tabela a seguir:
Cenário Valor Tipo de destino Endereços IP Endereços IP de destino/intervalos CIDR 0.0.0.0/0 Tipo de salto seguinte Dispositivo virtual Endereço do próximo salto O endereço IP privado do firewall copiado Na navegação à esquerda, selecione Sub-redes > Associar.
Em rede virtual, selecione a sua rede virtual integrada.
Em Sub-rede, selecione o HDInsight na sub-rede do AKS que pretende utilizar.
Selecione OK.
Configurar políticas de firewall
O tráfego de saída do seu HDInsight na sub-rede AKS agora é roteado através da rede virtual integrada para o firewall. Para controlar o tráfego de saída, adicione uma regra de aplicativo à diretiva de firewall.
Navegue até a página de visão geral do firewall e selecione sua política de firewall.
Na página de política de firewall, a partir da navegação à esquerda, adicione regras de rede e de aplicação. Por exemplo, selecione Regras de Rede > Adicionar uma coleção de regras.
Em Rules, adicione uma regra de rede com a sub-rede como endereço de origem e especifique um destino FQDN. Da mesma forma, adicione as regras de aplicação.
- Você precisa adicionar as regras de tráfego de saída indicadas aqui. Consulte este documento para adicionar regras de aplicativo e de rede para permitir que o tráfego para o cluster funcione. (O AKS ApiServer precisa ser adicionado após a criação do clusterPool porque você só pode obter o AKS ApiServer depois de criar o clusterPool).
- Você também pode adicionar os pontos de extremidade privados para quaisquer recursos dependentes na mesma sub-rede para que o cluster os acesse (exemplo – armazenamento).
Selecione Adicionar.
Verificar se o IP público foi criado
Com as regras de firewall definidas, você pode selecionar a sub-rede durante a criação do pool de clusters.
Depois que o pool de clusters é criado, você pode observar no Grupo MC que não há IP público criado.
Importante
Antes de criar o cluster na configuração do pool de clusters com Outbound with userDefinedRouting caminho de saída, você precisa dar ao cluster AKS - que corresponde ao pool de clusters - a função Network Contributor em seus recursos de rede que são usados para definir o roteamento, como Rede Virtual, Tabela de rotas e NSG (se usado). Saiba mais sobre como atribuir a função aqui
Observação
Quando você implanta um pool de clusters com caminho de saída UDR e um cluster de entrada privado, o HDInsight no AKS cria automaticamente uma zona DNS privada e mapeia as entradas para resolver o FQDN para acessar o cluster.
Criação de agrupamento de clusters com AKS privado
Com o AKS privado, o plano de controle ou servidor API tem endereços IP internos que são definidos no RFC1918 - Address Allocation for Private Internet document. Usando essa opção de AKS privado, você pode garantir que o tráfego de rede entre seu servidor de API e seus clusters de carga de trabalho do HDInsight no AKS permaneça apenas na rede privada.
Quando você provisiona um cluster AKS privado, o AKS por padrão cria um FQDN privado com uma zona DNS privada e um FQDN público adicional com um registro A correspondente no DNS público do Azure. Os nós do agente continuam a usar o registro na zona DNS privada para resolver o endereço IP privado do ponto de extremidade privado para comunicação com o servidor de API.
Como o HDInsight no AKS irá inserir automaticamente o registo na zona DNS privada no grupo gerido criado pelo HDInsight no AKS, para ingresso privado.
Clusters com entrada privada
Quando você cria um cluster com o HDInsight no AKS, ele tem um FQDN público e um endereço IP que qualquer pessoa pode acessar. Com o recurso de entrada privada, você pode garantir que apenas sua rede privada possa enviar e receber dados entre o cliente e o cluster HDInsight no AKS.
Observação
Com esse recurso, o HDInsight no AKS criará automaticamente registros A na zona DNS privada para entrada.
Esse recurso impede o acesso público à Internet para o cluster. O cluster obtém um balanceador de carga interno e IP privado. O HDInsight no AKS usa a zona DNS privada que o pool de clusters criou para conectar a Rede Virtual do cluster e fazer a resolução de nomes.
Cada cluster privado contém dois FQDNs: FQDN público e FQDN privado.
FQDN público: {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
O FQDN Público só pode ser resolvido para um CNAME com subdomínio, portanto, ele deve ser usado com o Private DNS zone setting correto para garantir que o FQDN possa ser finalmente resolvido para corrigir o endereço IP privado.
A zona DNS privada deve ser capaz de resolver FQDN privado para um IP (privatelink.{clusterPoolName}.{subscriptionId}).
Observação
O HDInsight no AKS cria uma zona DNS privada no pool de clusters, rede virtual. Se os aplicativos cliente estiverem na mesma rede virtual, você não precisará configurar a zona DNS privada novamente. Caso esteja a utilizar uma aplicação cliente numa rede virtual diferente, é necessário usar o emparelhamento de rede virtual e vincular à zona DNS privada na rede virtual do pool de clusters ou utilizar pontos de extremidade privados na rede virtual, e zonas DNS privadas, para adicionar o registo A ao IP privado do ponto de extremidade privado.
FQDN privado: {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
O FQDN privado será atribuído a clusters com a entrada privada habilitada somente. É um A-RECORD na zona DNS privada que se resolve para o IP privado do cluster.