Clusters isolados de rede do Serviço Kubernetes do Azure (AKS)

As organizações normalmente têm requisitos rigorosos de segurança e conformidade para regular o tráfego de rede de saída (saída) de um cluster para eliminar os riscos de exfiltração de dados. Por padrão, os clusters padrão do Serviço Kubernetes do Azure (AKS) têm acesso irrestrito à Internet de saída. Esse nível de acesso à rede permite que os nós e serviços que gere acedam a recursos externos conforme necessário. Se desejar restringir o tráfego de saída, um número limitado de portas e endereços deve estar acessível para assegurar a execução saudável das tarefas de manutenção do cluster. O documento conceitual sobre regras de rede de saída e nome de domínio totalmente qualificado (FQDN) para clusters AKS fornece uma lista de pontos de extremidade necessários para o cluster AKS e seus complementos e recursos opcionais.

Uma solução comum para restringir o tráfego de saída do cluster é usar um dispositivo de firewall para restringir o tráfego com base em regras de firewall. O firewall é aplicável quando seu aplicativo requer acesso de saída, mas quando as solicitações de saída precisam ser inspecionadas e protegidas. Configurar um firewall manualmente com as regras de saída e FQDNs necessários é um processo complicado, especialmente se seu único requisito for criar um cluster AKS isolado sem dependências de saída para a inicialização do cluster.

Para reduzir o risco de exfiltração de dados, o cluster isolado de rede permite inicializar o cluster AKS sem dependências de rede de saída, até mesmo para buscar componentes/imagens de cluster do Microsoft Artifact Registry (MAR). O operador de cluster pode configurar incrementalmente o tráfego de saída permitido para cada cenário que deseja habilitar.

Como funciona um cluster isolado de rede

O diagrama a seguir mostra a comunicação de rede entre dependências para um cluster isolado de rede.

Os clusters AKS buscam artefatos necessários para o cluster e seus recursos ou complementos do Microsoft Artifact Registry (MAR). Este pull de imagem permite que o AKS forneça versões mais recentes dos componentes do cluster e também resolva vulnerabilidades críticas de segurança. Um cluster isolado de rede tenta extrair essas imagens e binários de uma instância privada do Azure Container Registry (ACR) conectada ao cluster em vez de extrair do MAR. Se as imagens não estiverem presentes, o ACR privado obtém-nas do MAR e fornece-as através do seu ponto de extremidade privado, eliminando a necessidade de permitir a saída do cluster para o ponto de extremidade público do MAR.

As duas opções a seguir são suportadas para um ACR privado associado a clusters isolados de rede:

• ACR gerenciado pelo AKS - O AKS cria, gerencia e reconcilia um recurso ACR nesta opção. Não há nada que você precise fazer.

  Nota

  O recurso ACR gerenciado pelo AKS é criado em sua assinatura. Se você excluir o cluster com o ACR gerido pelo AKS como origem do artefato de bootstrap. Recursos relacionados, como o ACR gerido pelo AKS, ligação privada e endpoint privado também são excluídos automaticamente. Se alterar o tipo de saída num cluster para qualquer tipo que não seja none ou block com --bootstrap-artifact-source mantido como Cache. Em seguida, os recursos relacionados não são excluídos.

• Traga seu próprio ACR (BYO) - A opção BYO ACR requer a criação de um ACR com um link privado entre o recurso ACR e o cluster AKS. Consulte Conectar-se de forma privada a um registro de contêiner do Azure usando o Azure Private Link para entender como configurar um ponto de extremidade privado para seu registro. Você também precisa atribuir permissões e gerenciar as regras de cache, o link privado e o ponto de extremidade privado usados no cluster.

  Nota

  Quando você exclui o cluster AKS ou depois de desativar o recurso. O ACR BYO, o link privado e o ponto de acesso privado não são eliminados automaticamente. Se você adicionar imagens personalizadas e regras de cache ao BYO ACR, elas persistirão após a reconciliação do cluster.

Para criar um cluster isolado de rede, você precisa primeiro garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça apenas na rede privada, você pode escolher um dos seguintes modos de cluster privado:

• Cluster baseado em ligação privada - O plano de controlo ou o servidor de API está num grupo de recursos do Azure gerido pelo AKS e o seu pool de nós está no seu grupo de recursos. O servidor e o pool de nós podem comunicar-se entre si por meio do serviço Azure Private Link na rede virtual do servidor de API e de um ponto de extremidade privado que está localizado na sub-rede do seu cluster AKS.
• Cluster configurado para Integração de VNet do Servidor de API - Um cluster configurado com a Integração de VNet do Servidor de API projeta o ponto final do servidor de API diretamente numa sub-rede delegada na rede virtual onde o AKS é implementado. A integração de VNet do Servidor de API permite a comunicação de rede entre o servidor de API e os nós do cluster sem a necessidade de um link ou túnel privado.

Você também precisa garantir que o caminho de saída para seu cluster AKS seja controlado e limitado, você pode escolher um dos seguintes tipos de saída de rede:

• Tipo de saída de none - Se none está definido. O AKS não configura automaticamente os caminhos de saída e uma rota padrão não é necessária. É suportado tanto em cenários de rede virtual trazidos pelo próprio utilizador (BYO) como em cenários de rede virtual gerenciada. Para trazer seu próprio cenário de rede virtual, você deve estabelecer caminhos de saída explícitos, se necessário.
• O tipo de saída de block (visualização) -If block está definido. O AKS configura regras de rede para bloquear ativamente todo o tráfego de saída do cluster. Esta opção é útil para ambientes altamente seguros onde a conectividade de saída deve ser restrita. Ele é suportado no cenário de rede virtual gerenciada. Você também pode obter um efeito semelhante bloqueando todo o tráfego de saída, ao adicionar regras do grupo de segurança de rede (NSG) no cenário de rede virtual própria.

Limitações

• Unmanaged canal não é suportado.
• Os pools de nós do Windows ainda não são suportados.
• A rede Kubenet não é suportada.

Usando recursos, complementos e extensões que exigem saída

Para clusters isolados de rede com BYO ACR:

• Se você quiser usar qualquer recurso ou complemento do AKS que exija acesso à rede de saída em clusters isolados de rede com tipo none de saída, este documento contém os requisitos de rede de saída para cada recurso. Além disso, este documento enumera os recursos ou complementos que oferecem suporte à integração de link privado para conexão segura de dentro da rede virtual do cluster. Recomenda-se configurar endpoints privados para aceder a estas funcionalidades. Por exemplo, você pode configurar a ingestão baseada em ponto de extremidade privado para usar o Managed Prometheus (espaço de trabalho do Azure Monitor) e o Container insights (espaço de trabalho do Log Analytics) em clusters isolados de rede. Se uma integração de link privado não estiver disponível para qualquer um desses recursos. Em seguida, você pode configurar o cluster com uma tabela de roteamento definida pelo usuário e um Firewall do Azure com base nas regras de rede e regras de aplicativo necessárias para esse recurso.
• Se você estiver usando o driver CSI (Interface de Armazenamento de Contêiner) do Azure para Arquivos do Azure e armazenamento de Blob, deverá criar uma classe de armazenamento personalizada com "networkEndpointType: privateEndpoint", consulte exemplos em classes de armazenamento de Arquivos do Azure e classes de armazenamento de Blob do Azure.
• As seguintes extensões de cluster AKS ainda não são suportadas em clusters isolados de rede:
  • Dapr
  • Configuração do Aplicativo do Azure
  • Azure Machine Learning
  • Fluxo (GitOps)
  • Backup do Azure para AKS

Perguntas mais frequentes

Qual é a diferença entre o cluster isolado de rede e o Firewall do Azure?

Um cluster isolado de rede não requer nenhum tráfego de saída além da VNet durante todo o processo de inicialização do cluster. Um cluster isolado de rede tem o tipo de saída como none ou block. Se o tipo de saída estiver definido como none, o AKS não configura nenhuma conexão de saída para o cluster, permitindo que o usuário as configure por conta própria. Se o tipo de saída estiver definido como block, todas as conexões de saída serão bloqueadas.

Um firewall normalmente estabelece uma barreira entre uma rede confiável e uma rede não confiável, como a Internet. O Firewall do Azure, por exemplo, pode restringir o tráfego HTTP e HTTPS de saída baseado no destino. Ele oferece um controle refinado do tráfego de saída, mas, ao mesmo tempo, permite que você forneça acesso aos FQDNs que abrangem as dependências de saída de um cluster AKS. Isso é algo que os NSGs não podem fazer. Por exemplo, pode definir o tipo de saída do cluster para userDefinedRouting, forçando o tráfego de saída através do firewall e, em seguida, configurar restrições de FQDN no tráfego de saída. Há muitos casos em que você ainda quer um firewall. Você já possui tráfego de saída da sua aplicação ou deseja controlar, inspecionar e proteger tanto o tráfego de saída quanto o de entrada do cluster.

Em resumo, enquanto o Firewall do Azure pode ser usado para definir restrições de saída em clusters com solicitações de saída, os clusters isolados de rede vão além na postura segura por padrão, eliminando ou bloqueando completamente as solicitações de saída.

Preciso configurar algum ponto de extremidade de lista de permissões para que o cluster isolado de rede funcione?

Os estágios de criação e inicialização do cluster não exigem nenhum tráfego de saída do cluster isolado da rede. As imagens necessárias para os componentes e addons do AKS são obtidas do ACR privado conectado ao cluster, em vez de serem obtidas do Microsoft Artifact Registry (MAR) através de endpoints públicos.

Depois de configurar um cluster isolado de rede. Se quiser habilitar recursos ou complementos que precisam fazer solicitações de saída para seus pontos de extremidade de serviço, você pode configurar pontos de extremidade privados para os serviços alimentados pelo Azure Private Link.

Posso atualizar manualmente os pacotes para atualizar a imagem do pool de nós?

Não é recomendável atualizar manualmente os pacotes com base na saída para repositórios de pacotes. Em vez disso, você pode atualizar manualmente ou atualizar automaticamente as imagens do sistema operacional do nó. Atualmente, apenas NodeImage e None canais de atualização são suportados para clusters isolados de rede.

E se eu alterar o tipo de saída diferente de none ou block, isso ainda torna um cluster de rede isolado?

Os únicos tipos de saída suportados para um cluster isolado de rede são o tipo de saída none e block. Se você usar qualquer outro tipo de saída, o cluster ainda poderá extrair artefatos do ACR privado associado, no entanto, isso pode gerar tráfego de saída.

Próximos passos

• Criar um cluster isolado de rede