Controlar o tráfego de rede do HDInsight em pools de clusters e clusters do AKS
Importante
O Azure HDInsight no AKS se aposentou em 31 de janeiro de 2025. Saiba mais com este comunicado.
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
Esse recurso está atualmente em versão prévia. Os termos de uso complementares para o Microsoft Azure Previews incluem mais termos legais que se aplicam aos recursos do Azure que estão em versão beta, em versão prévia ou ainda não lançados em disponibilidade geral. Para obter informações sobre essa versão prévia específica, consulte as informações de visualização do Azure HDInsight no AKS . Para perguntas ou sugestões de funcionalidades, envie uma solicitação em AskHDInsight com os detalhes e siga-nos para obter mais atualizações da Comunidade do Azure HDInsight em .
O HDInsight no AKS é uma PaaS (Plataforma como Serviço) gerenciada que é executada no AKS (Serviço de Kubernetes do Azure). 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 dos clusters para qualquer destino, desde que o destino seja acessível pela 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, talvez você queira:
Impedir que os clusters acessem serviços mal-intencionados ou indesejados.
Impor 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 diferentes opções e ferramentas para gerenciar como o tráfego de saída flui do HDInsight em clusters do 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 recomendável. 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/Nat Gateway e tabelas de rotas personalizadas. Essa opção só está disponível ao usar uma VNET personalizada.
Ative o AKS privado. Quando você habilitar o AKS privado no pool de clusters, o servidor de API do AKS receberá 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 em pools de nós do AKS (clusters) permanecerá 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 de clientes na mesma VNET. Você deve fornecer sua própria solução NAT, como um gateway NAT ou um NAT fornecido pelo seu firewall, para se conectar a dependências de saída públicas 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 saída do balanceador de carga no pool de clusters, você pode esperar saída do balanceador de carga criado pelo HDInsight no AKS.
Você pode configurar o tráfego de saída usando a configuração do balanceador de carga no portal do Azure.
Depois de optar por essa configuração, o HDInsight no AKS concluirá automaticamente a criação de um endereço IP público provisionado para saída de cluster, que 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 de IP público.
Quando os clusters são criados, determinados 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 determinadas regras no NSG para obter um controle mais geral.
Saída com roteamento definido pelo usuário
Nota
O tipo de saída userDefinedRouting é um cenário de rede avançado e requer uma configuração de rede adequada antes de começar.
Alterar o tipo de saída após a criação do pool de clusters não é suportado.
Se userDefinedRouting estiver definido, o HDInsight no AKS não configurará automaticamente caminhos de saída. A configuração de saída deve ser feita pelo usuário.
Você deve implementar o HDInsight no cluster AKS em uma rede virtual existente com uma sub-rede que foi configurada anteriormente, e deve configurar saída explícita.
Essa arquitetura requer o envio explícito de tráfego de saída para um dispositivo como um 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 (Conversão de Endereços de Rede).
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 "Outbound" com balanceador de carga, conforme descrito na seção acima. Sua UDR é a única origem para o tráfego de saída.
Para o tráfego de entrada, você deve escolher com base nos requisitos para escolher um cluster privado (para proteger o tráfego no plano de controle do AKS/servidor de API) e selecionar a opção de entrada privada disponível em cada uma das formas do cluster para usar o tráfego público ou interno baseado em balanceador de carga.
Criação de pool de cluster para saída com userDefinedRouting
Quando você usa o HDInsight em pools de cluster do 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 do UDR precisa de uma rota para 0.0.0.0/0 e de um próximo salto para 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 com a Internet de saída apenas adicionando essa rota, pois 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 sim 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 balanceador de carga. 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 do Azure de back-end ou outros recursos de rede com o Firewall do Azure. Essa configuração ajuda a impedir a exfiltração de dados ou o risco de implantação de programa mal-intencionado.
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 contra ameaças em tempo real da Microsoft Cyber Security. Você pode criar, impor e registrar políticas de conectividade de rede e aplicativo centralmente entre assinaturas e redes virtuais.
Veja a seguir um exemplo de como configurar regras de firewall e testar suas conexõ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.
No menu à esquerda, selecione Subnets > + Subnet.
Em Nome, digite AzureFirewallSubnet .
intervalo de endereços de sub-rede, aceitar o padrão ou especificar um intervalo com tamanho de pelo menos /26.
Selecione Salvar.
Implantar o firewall e obter seu IP
No menu do portal do Azure ou na página Página Inicial, selecione Criar um recurso.
Digite firewall na caixa de pesquisa e pressione Enter.
Selecione firewall e selecione Criar.
Na página Criar um Firewall, configure o firewall, conforme mostrado na tabela a seguir:
Configuração Valor Grupo de recursos Mesmo grupo de recursos que a rede virtual integrada. Nome Nome de 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 em 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 Visão Geral do firewall, copie o endereço IP privado. O endereço IP privado será usado como endereço de próximo salto na regra de roteamento para a rede virtual.
Rotear 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 sistema à tabela. Nesta etapa, você criará uma tabela de rotas definida pelo usuário que roteia todo o tráfego para o firewall e, em seguida, associe-a à 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.
Em Rede, selecione Tabelas de rotas.
Selecione Adicionar.
Configure a tabela de rotas como o exemplo a seguir:
Selecione a mesma região que o firewall que você criou.
Selecione Revisão + Criar.
Selecione Criar.
Após a conclusão da implantação, selecione Ir para o recurso.
No menu à esquerda, selecione Rotas > Adicionar.
Configure a nova rota, conforme mostrado na tabela a seguir:
Configuração Valor Tipo de destino Endereços IP Endereços IP de destino/intervalos CIDR 0.0.0.0/0 Tipo de próximo salto Dispositivo virtual Endereço do próximo salto O endereço IP privado para o firewall que você copiou Na navegação à esquerda, selecione Sub-redes > Associar.
Na rede virtual , selecione sua rede virtual integrada.
Na sub-rede , selecione o HDInsight na sub-rede do AKS que você deseja usar.
Selecione OK.
Configurar políticas de firewall
O tráfego de saída do HDInsight na sub-rede do AKS agora é roteado por meio da rede virtual integrada para o firewall. Para controlar o tráfego de saída, adicione uma regra de aplicativo à política 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, da navegação à esquerda, adicione regras de rede e de aplicativo. Por exemplo, selecione Regras de Rede > Adicionar uma coleção de regras.
Em Regras, adicione uma regra de rede com a sub-rede como o endereço de origem e especifique um destino FQDN. Da mesma forma, adicione as regras do aplicativo.
- Você precisa adicionar as regras de tráfego de saída fornecidas aqui. Consulte este documento para adicionar regras de aplicação e de rede a fim de permitir o tráfego necessário para o funcionamento do cluster. (O AKS ApiServer precisa ser adicionado depois que o clusterPool é criado porque você só pode obter o AKS ApiServer depois de criar o clusterPool).
- Você também pode adicionar os pontos de extremidade privados para todos os 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 for criado, você poderá observar no Grupo MC que não há nenhum IP público criado.
Importante
Antes de você criar o Cluster no conjunto do pool de clusters com o caminho de saída Outbound with userDefinedRouting, é necessário conceder ao Cluster AKS - que corresponde ao pool de clusters - a função Network Contributor nos seus recursos de rede usados para definir o roteamento, incluindo Rede Virtual, Tabela de Rotas e NSG (se usado). Saiba mais sobre como atribuir a função aqui
Nota
Quando você implanta um pool de clusters com o caminho de saída UDR e um cluster de entrada privado, o HDInsight no AKS criará automaticamente uma zona DNS privada e mapeará as entradas para resolver o FQDN para acessar o cluster.
Criação de pool de cluster com AKS privado
Com o AKS privado, o plano de controle ou o servidor de API tem endereços IP internos definidos no RFC1918 – Alocação de Endereço para Internet Privadadocumento. Usando essa opção de AKS privado, você pode garantir que o tráfego de rede entre o servidor de API e o HDInsight em clusters de carga de trabalho do AKS permaneça apenas na rede privada.
Quando você provisiona um cluster privado do AKS, 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 utilizar o registro na zona DNS privada para obter o endereço IP do endpoint privado e assim se comunicar com o servidor de API.
Como o HDInsight no AKS irá inserir automaticamente o registro na zona DNS privada no grupo gerenciado criado pelo HDInsight no AKS, para acesso privado.
Clusters com entrada privada
Quando você cria um cluster com 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 somente sua rede privada possa enviar e receber dados entre o cliente e o HDInsight no cluster do AKS.
Nota
Com esse recurso, o HDInsight no AKS criará automaticamente registros A na zona DNS privada para ingresso.
Esse recurso impede o acesso público à Internet ao cluster. O cluster obtém um balanceador de carga interno e um IP privado. O HDInsight no AKS usa a zona DNS privada que o pool de cluster 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 o FQDN privado para um IP (privatelink.{clusterPoolName}.{subscriptionId}).
Nota
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 usando um aplicativo cliente em uma rede virtual diferente, você precisará usar o emparelhamento de rede virtual e associar-se à zona DNS privada na rede virtual do pool de clusters, ou usar pontos de extremidade privados na rede virtual e zonas DNS privadas para adicionar o registro 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 apenas. É um registro A na zona DNS privada que direciona para o IP privado do cluster.