Acesso seguro à rede do Kubernetes

Este artigo compara os modos de rede do Azure Kubernetes Service (AKS) e do Amazon Elastic Kubernetes Service (Amazon EKS). O artigo descreve como melhorar a segurança da conexão com o servidor de API gerenciado de um cluster AKS e as diferentes opções para restringir o acesso à rede pública.

Modos de rede do Amazon EKS

Com a Amazon Virtual Private Cloud (Amazon VPC), você pode executar recursos da Amazon Web Services (AWS) em uma rede virtual composta por sub-redes públicas e privadas ou intervalos de endereços IP na VPC. Uma sub-rede pública hospeda recursos que devem estar conectados à Internet e uma sub-rede privada hospeda recursos que não estão conectados à Internet pública. O Amazon EKS pode provisionar grupos de nós gerenciados em sub-redes públicas e privadas.

O controle de acesso ao endpoint permite configurar se o ponto de extremidade do Servidor de API pode ser acessado pela Internet pública ou por meio da VPC. O EKS fornece várias maneiras de controlar o acesso ao ponto de extremidade do cluster. Você pode habilitar o ponto de extremidade público padrão, um ponto de extremidade privado ou ambos os pontos de extremidade simultaneamente. Ao habilitar o ponto de extremidade público, você pode adicionar restrições CIDR (Roteamento entre Domínios sem Classe) para limitar os endereços IP do cliente que podem se conectar ao ponto de extremidade público.

A forma como os nós do Amazon EKS se conectam ao plano de controle do Kubernetes gerenciado é determinada pela configuração de endpoint configurada para o cluster. Você pode alterar as configurações do endpoint a qualquer momento por meio do console do Amazon EKS ou da API. Para obter mais informações, consulte Controle de acesso ao endpoint do cluster do Amazon EKS.

Apenas ponto de extremidade público

Expor o plano de controle por meio de um endpoint público é o modo padrão para novos clusters do Amazon EKS. Quando apenas o endpoint público do cluster está habilitado, as solicitações de API do Kubernetes originadas na Amazon VPC, como o nó de trabalho para controlar a comunicação do plano, saem da VPC, mas não saem da rede da Amazon. Para que os nós se conectem ao plano de controle, eles devem usar um endereço IP público e uma rota para um gateway da Internet ou uma rota para um gateway NAT (conversão de endereços de rede) onde possam usar o endereço IP público do gateway NAT.

Parâmetros de avaliação públicos e privados

Quando os endpoints público e privado estão habilitados, as solicitações de API do Kubernetes de dentro da VPC se comunicam com o plano de controle por meio das Interfaces de Rede Elástica (ENIs) gerenciadas pelo Amazon EKS na VPC. O servidor de API de cluster é acessível a partir da Internet.

Apenas ponto de extremidade privado

Quando apenas o ponto de extremidade privado está habilitado, todo o tráfego para o servidor de API do cluster, como kubectl comandos ou helm comandos, deve vir de dentro da VPC do cluster ou de uma rede conectada. O acesso público ao servidor de API a partir da Internet está desativado. Você pode implementar esse modo de acesso usando a AWS Virtual Private Network (AWS VPN) ou o AWS DirectConnect para a VPC. Para restringir o acesso ao endpoint sem AWS VPN ou DirectConnect, você pode adicionar restrições CIDR ao endpoint público para limitar conexões sem configurar mais rede.

Para obter mais informações sobre opções de conectividade, consulte Acessando um servidor de API somente privado.

Acesso à rede AKS ao servidor API

Há duas opções para proteger o acesso à rede à API do Kubernetes no AKS, um cluster AKS privado ou intervalos de IP autorizados.

Cluster AKS privado

Um cluster privado AKS garante que o tráfego de rede entre o servidor de API e os pools de nós permaneça dentro da rede virtual. Em um cluster AKS privado, o plano de controle ou servidor de API tem um endereço IP interno que só é acessível por meio de um ponto de extremidade privado do Azure localizado na mesma rede virtual. Qualquer máquina virtual (VM) na mesma rede virtual pode se comunicar de forma privada com o plano de controle por meio do ponto de extremidade privado. O plano de controle ou servidor de API é hospedado na assinatura gerenciada pelo Azure, enquanto o cluster AKS e seus pools de nós estão na assinatura do cliente.

O diagrama a seguir ilustra uma configuração de cluster privado.

Transfira um ficheiro do Visio desta arquitetura.

Para provisionar um cluster AKS privado, o provedor de recursos AKS cria um FQDN (nome de domínio totalmente qualificado) privado para o grupo de recursos do nó em uma zona DNS privada. Opcionalmente, o AKS também pode criar um FQDN público com um registro de endereço (A) correspondente na zona DNS pública do Azure. Os nós do agente usam o A registro na zona DNS privada para resolver o endereço IP do ponto de extremidade privado para comunicação com o servidor de API.

O provedor de recursos AKS pode criar a zona DNS privada no grupo de recursos do nó ou você pode criar a zona DNS privada e passar seu ID de recurso para o sistema de provisionamento. Você pode criar um cluster privado ao usar o Terraform com Azure, Bicep, modelos ARM, CLI do Azure, módulo do Azure PowerShell ou API REST do Azure para criar o cluster.

Você pode habilitar um FQDN público para o servidor de API durante o provisionamento ou usando o comando az aks update com o --enable-public-fqdn parâmetro em clusters existentes. Se você habilitar o FQDN público, qualquer VM que acesse o servidor, como um agente auto-hospedado do Azure DevOps ou um corredor auto-hospedado do GitHub Actions, deverá estar na mesma rede virtual que hospeda o cluster ou em uma rede conectada por meio de emparelhamento de rede virtual ou VPN site a site.

Para um cluster AKS privado, desative o FQDN público do servidor de API. Para se comunicar com o plano de controle privado, uma VM deve estar na mesma rede virtual ou em uma rede virtual emparelhada com um link de rede virtual para a zona DNS privada. O A registro na zona DNS privada resolve o FQDN do servidor de API para o endereço IP do ponto de extremidade privado que se comunica com o plano de controle subjacente. Para obter mais informações, veja Criar um cluster do Azure Kubernetes Service privado.

Opções de implantação de cluster privado

O provedor de recursos AKS expõe os seguintes parâmetros para personalizar a implantação privada do cluster AKS:

• authorizedIpRanges (string) especifica intervalos de IP permitidos no formato CIDR.
• disableRunCommand (Booleano) especifica se o comando para o cluster deve ou não ser desabilitado run .
• enablePrivateCluster (Booleano) especifica se o cluster deve ou não ser criado como privado.
• enablePrivateClusterPublicFQDN (Booleano) especifica se deve ou não ser criado outro FQDN público para o cluster privado.
• privateDnsZone (string) especifica uma zona DNS privada no grupo de recursos do nó. Se você não especificar um valor, o provedor de recursos criará a zona. Você pode especificar os seguintes valores:
  • System é o valor padrão.
  • None o padrão é o DNS público, portanto, o AKS não cria uma zona DNS privada.
  • <Your own private DNS zone resource ID> usa uma zona DNS privada que você cria no formato privatelink.<region>.azmk8s.io ou <subzone>.privatelink.<region>.azmk8s.io.

A tabela a seguir mostra as opções de configuração de DNS para implantar um cluster AKS privado:

Conectividade e gerenciamento de cluster privado

Existem várias opções para estabelecer conectividade de rede com o cluster privado.

• Crie VMs na mesma rede virtual que o cluster AKS.

• Use VMs em uma rede virtual separada e configure o emparelhamento de rede virtual com a rede virtual de cluster AKS .

• Use uma conexão Azure ExpressRoute ou VPN .

• Use o comando az aks da CLI do Azure invoke para executar kubectl comandos no helm cluster privado sem se conectar diretamente ao cluster.

• Use uma conexão de Ponto de Extremidade Privado do Azure.

Você pode gerenciar um cluster AKS privado usando a ferramenta de linha de comando kubectl de uma VM de gerenciamento na mesma rede virtual ou em uma rede virtual emparelhada.

Você pode usar o Azure Bastion na mesma rede virtual ou em uma rede virtual emparelhada para se conectar a uma VM de gerenciamento de jumpbox. O Azure Bastion é uma plataforma como serviço (PaaS) totalmente gerenciada que permite que você se conecte a uma VM usando seu navegador e o portal do Azure. O Azure Bastion fornece conectividade de VM segura e contínua RDP (Remote Desktop Protocol) ou SSH (Secure Shell) sobre TLS (Transport Layer Security) diretamente do portal do Azure. Quando as VMs se conectam por meio do Azure Bastion, elas não precisam de um endereço IP público, agente ou software cliente especial.

Você também pode usar o comando az aks invoke para executar kubectl ou helm comandos em seu cluster AKS privado sem ter que se conectar a uma VM jumpbox.

Intervalos de IP autorizados

A segunda opção para melhorar a segurança do cluster e minimizar os ataques ao servidor de API é usar intervalos de IP autorizados. IPs autorizados restringem o acesso ao plano de controle de um cluster AKS público a uma lista conhecida de endereços IP e CIDRs. Quando você usa essa opção, o servidor de API ainda é exposto publicamente, mas o acesso é limitado. Para obter mais informações, consulte Acesso seguro ao servidor de API usando intervalos de endereços IP autorizados no Serviço Kubernetes do Azure (AKS).

O seguinte az aks update comando da CLI do Azure autoriza intervalos de IP:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Considerações sobre conectividade do AKS

• Um cluster privado AKS oferece maior segurança e isolamento do que os IPs autorizados. No entanto, não é possível converter um cluster AKS público existente em um cluster privado. Você pode habilitar IPs autorizados para qualquer cluster AKS existente.

• Não é possível aplicar intervalos de IP autorizados a um ponto de extremidade de servidor de API privado. Os IPs autorizados aplicam-se apenas ao servidor de API público.

• Os clusters privados não suportam agentes hospedados pelo Azure DevOps. Considere o uso de agentes auto-hospedados.

• Para permitir que o Registro de Contêiner do Azure funcione com um cluster AKS privado, configure um link privado para o registro de contêiner na rede virtual do cluster. Ou configure o emparelhamento entre a rede virtual do Registro de Contêiner e a rede virtual do cluster privado.

• As limitações do serviço Azure Private Link aplicam-se a clusters privados.

• Se você excluir ou modificar o ponto de extremidade privado na sub-rede do cliente de um cluster privado, o cluster deixará de funcionar.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Paolo Salvatori - Brasil | Engenheiro de Serviços Principal
• Martin Gjoshevski - Brasil | Engenheiro de Serviços Sênior
• Laura Nicolas - Brasil | Engenheiro de Software Sênior

Outros contribuidores:

• Chade Kittel - Brasil | Engenheiro de Software Principal
• Ed Preço | Gerente de Programa de Conteúdo Sênior
• Theano Petersen - Brasil | Redator Técnico

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• AKS para profissionais do Amazon EKS
• Gerenciamento de identidade e acesso do Kubernetes
• Monitoramento e registro em log do Kubernetes
• Opções de armazenamento para um cluster Kubernetes
• Gestão de custos para Kubernetes
• Gerenciamento de nós e pool de nós do Kubernetes
• Governança de cluster

Recursos relacionados

As referências a seguir fornecem links para exemplos de documentação e automação para implantar clusters AKS com uma API segura:

• Criar um cluster AKS privado com uma zona DNS pública
• Criar um cluster privado do Serviço Kubernetes do Azure usando o Terraform e o Azure DevOps
• Criar um cluster de Serviço Kubernetes do Azure público ou privado com o Azure NAT Gateway e o Azure Application Gateway
• Usar pontos de extremidade privados com um cluster privado do AKS
• Introdução ao Azure Private Link
• Introdução à Infraestrutura de Rede Segura com Segurança de Rede do Azure