Controle o tráfego de rede do HDInsight em pools e clusters do Cluster do AKS
Observação
Desativaremos o Microsoft Azure HDInsight no AKS em 31 de janeiro de 2025. Para evitar o encerramento abrupto das suas cargas de trabalho, você precisará migrá-las para o Microsoft Fabric ou para um produto equivalente do Azure antes de 31 de janeiro de 2025. Os clusters restantes em sua assinatura serão interrompidos e removidos do host.
Somente o suporte básico estará disponível até a data de desativação.
Importante
Esse recurso está atualmente na visualização. Os Termos de uso complementares para versões prévias do Microsoft Azure 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, confira Informações sobre a versão prévia do Azure HDInsight no AKS. Caso tenha perguntas ou sugestões de recursos, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para ver mais atualizações sobre a Comunidade do Azure HDInsight.
O HDInsight no AKS é uma plataforma como serviço (PaaS) gerenciada que é executada no Serviço de 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 do AKS permite conexões de rede de saída de clusters para qualquer destino, se o destino for acessível a partir do adaptador 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, é possível fazer o seguinte:
Impeça que os clusters acessem serviços mal-intencionados ou indesejados.
Imponha 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 algumas delas no nível do pool do cluster e outras 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 de 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 os Grupos de Segurança de Rede (NSGs) 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 da NAT e tabelas de rotas personalizadas. Essa opção só está disponível quando se usa uma VNET personalizada.
Habilitar o AKS Privado. Quando você habilitar o AKS privado em seu pool de clusters, o servidor de API do AKS receberá um endereço IP interno e não poderá ser acessado publicamente. O tráfego de rede entre o servidor de API do AKS e o HDInsight nos pools de nós (clusters) do AKS 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ó poderá ser acessado por clientes dentro da mesma VNET. Você deve fornecer sua própria solução NAT, como um Gateway da NAT ou um NAT fornecido por seu firewall, para se conectar a 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 a saída por meio de um HDInsight no IP público atribuído pelo AKS. Ao configurar o tipo de balanceador de carga de saída em seu pool de clusters, você pode esperar a 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 concluirá automaticamente a criação de um endereço IP público provisionado para saída de cluster e atribuirá 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 exige 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 incluir o tráfego na lista de permissões. Você também pode configurar determinadas regras no NSG para fazer um controle de granulação grosseira.
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 uma 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 de saída deve ser feita pelo usuário.
Você deve implantar o HDInsight em um cluster do AKS em uma rede virtual existente com uma sub-rede que foi configurada previamente, e é necessário estabelecer uma 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 padrão ou dispositivo possa lidar com a Conversão de Endereços de Rede (NAT).
O HDInsight no AKS não configura um endereço IP público de saída nem 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, 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 forma de 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 o userDefinedRouting (UDR) como caminho de saída, não há um 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 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 o 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 o 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 de 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 de back-end do Azure ou outros recursos de rede com o Firewall do Azure. Essa configuração ajuda a evitar exfiltração dos 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 refinado e filtrar o tráfego com base na inteligência contra ameaças em tempo real do Microsoft Cyber Security. É possível criar, impor e registrar centralmente políticas de conectividade de rede e de aplicativo em assinaturas e redes virtuais.
Veja a seguir um exemplo de configuração de regras de firewall e teste de 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.
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 tenha pelo menos /26 de tamanho.
Selecione Salvar.
Implantar o firewall e obter seu IP
No menu do portal do Azure ou na Página Inicial, 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 abaixo:
Configuração Valor Grupo de recursos Mesmo grupo de recursos que a rede virtual integrada. Nome Nome de sua preferência Region Mesma região que a 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, acesse 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 da rede virtual.
Rotear todo o tráfego para o firewall
Ao criar uma rede virtual, o Azure cria automaticamente uma tabela de rotas padrão para cada uma das sub-redes dela e adiciona as rotas de sistema padrão à tabela. Nesta etapa, você cria uma tabela de rotas definida pelo usuário que roteia todo o tráfego para o firewall e, em seguida, associa-o à sub-rede do Serviço de Aplicativo na rede virtual integrada.
No menu do portal do Azure, selecione Todos os recursos ou, em qualquer página, pesquise por Todos os serviços e selecione essa opção.
Em Rede, selecione Tabelas de rotas.
Selecione Adicionar.
Configure a tabela de rotas como o seguinte exemplo:
Você deve selecionar a mesma região que o firewall que você criou.
Selecione Examinar + criar.
Selecione Criar.
Após a implantação ser concluída, selecione Ir para o recurso.
Na navegação à esquerda, selecione Rotas > Adicionar.
Configure a nova rota, conforme mostrado na seguinte tabela:
Configuração Valor Tipo de destino Endereços IP Intervalos de CIDR /endereço IP de destino 0.0.0.0/0 Tipo do próximo salto Solução de virtualização 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.
Em Rede virtual, selecione a sua rede virtual integrada.
Em 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 a respectiva política de firewall.
Na página da política de firewall, no painel de 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. Veja este documento para adicionar regras de aplicativo e de rede, a fim de permitir que o tráfego do cluster funcione. (O ApiServer do AKS precisa ser adicionado depois que o clusterPool é criado porque você só pode obter o ApiServer do AKS 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
Para criar o cluster na configuração do pool de clusters com o caminho de saída Outbound with userDefinedRouting
, você precisa conceder ao cluster do AKS, que corresponde ao pool de clusters, a função Network Contributor
nos 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ê implantar um pool de clusters com caminho de saída de 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 painel de controle ou o servidor de API têm endereços IP internos definidos na documentação RFC1918 – alocação de endereço para a Internet privada. Usando esta opção de AKS privado, é possível 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 do 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 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 somente sua rede privada possa enviar e receber dados entre o cliente e o HDInsight no cluster do AKS.
Observação
Com este recurso, o HDInsight no AKS criará automaticamente registros A na zona DNS privada para entrada.
Esse recurso impede o acesso público da 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 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 em um CNAME com subdomínio, portanto, deve ser usado com o Private DNS zone setting
correto para garantir que o FQDN possa ser finalmente resolvido no endereço IP privado correto.
A zona DNS privada deve ser capaz de resolver o 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 você esteja usando um aplicativo cliente em uma rede virtual diferente, é necessário usar o emparelhamento de rede virtual e associar-se à zona DNS privada na rede virtual do pool de clusters ou usar pontos de extremidade privadas 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 somente a clusters com a entrada privado habilitada. É um REGISTO A na zona DNS privada que resolve para o IP privado do cluster.