Controle o tráfego de rede do HDInsight em pools e clusters do AKS Cluster
Nota
Vamos desativar o Azure HDInsight no AKS em 31 de janeiro de 2025. Antes de 31 de janeiro de 2025, você precisará migrar suas cargas de trabalho para o Microsoft Fabric ou um produto equivalente do Azure para evitar o encerramento abrupto de suas cargas de trabalho. Os clusters restantes na sua subscrição serão interrompidos e removidos do anfitrião.
Apenas o apoio básico estará disponível até à data da reforma.
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 disponibilidade geral. Para obter informações sobre essa visualização específica, consulte Informações de visualização do Azure HDInsight no AKS. Para perguntas ou sugestões de recursos, 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 que você implante 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 diferentes opções e ferramentas para gerenciar como o tráfego de saída flui 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 em pools de nós 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 a partir de clientes dentro da mesma VNET. Você deve fornecer sua própria solução NAT, como um gateway NAT ou um NAT fornecido pelo firewall, para se conectar ao HDInsight público de saída nas dependências do 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 a saída com a configuração do balanceador de carga usando o portal do Azure.
Depois de optar por essa 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 & 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 permitir a lista de tráfego. Você também pode configurar certas regras no NSG para fazer um controle de grão grosso.
Saída com roteamento definido pelo usuário
Nota
O userDefinedRouting
tipo de saída é um cenário de rede avançado e requer configuração de rede adequada, antes de começar.
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 userDefinedRouting
de 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. Pode criar, impor e registar centralmente políticas de conectividade de rede e aplicações entre subscrições 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 com pelo menos /26 de tamanho.
Selecione Guardar.
Implante o firewall e obtenha seu IP
No menu do portal do Azure ou a partir da Home Page, 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 a seguir:
Definição Value Grupo de recursos Mesmo grupo de recursos que a rede virtual integrada. Nome Nome da sua escolha País/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 Rever + 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 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 procure 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:
Certifique-se de selecionar a mesma região do firewall que você criou.
Selecione Rever + criar.
Selecione Criar.
Após a conclusão da implantação, selecione Ir para o recurso.
Na navegação à esquerda, selecione Adicionar rotas>.
Configure a nova rota conforme mostrado na tabela a seguir:
Definição Value Tipo de Destino Endereços IP Endereços IP de destino/intervalos CIDR 0.0.0.0/0 Tipo de salto seguinte Aplicação virtual Endereço do próximo salto O endereço IP privado do firewall copiado Na navegação à esquerda, selecione Subnets > Associate.
Em Rede virtual, selecione sua rede virtual integrada.
Em Sub-rede, selecione o HDInsight na sub-rede AKS que você deseja usar.
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 Regras, 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ânsito de saída dadas aqui. Consulte este documento para adicionar regras de aplicativo e 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 Network Contributor
função 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
Nota
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 pool de clusters com AKS privado
Com o AKS privado, o plano de controle ou servidor de API tem endereços IP internos que são definidos no documento RFC1918 - Address Allocation for Private Internet. 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 aprovisiona um cluster privado do AKS, por predefinição, o AKS cria um FQDN privado com uma zona DNS privada e um FQDN público adicional com um registo 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 inserirá automaticamente o registro na zona DNS privada no grupo gerenciado criado pelo HDInsight no AKS, para entrada privada.
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.
Nota
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 correto Private DNS zone setting
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})
.
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, é necessário usar emparelhamento de rede virtual e vincular a 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 somente. É um A-RECORD na zona DNS privada que resolve para o IP privado do cluster.
Referência
Introdução aos Clusters Privados no HDInsight no AKS para proteger suas cargas de trabalho de análise.
Roteamento de tráfego de rede virtual do Azure.
Emparelhamento de Rede Virtual do Azure.
Tráfego de saída no HDInsight no AKS - Azure HDInsight no AKS