Melhore a segurança de acesso à rede para o Kubernetes

2025-04-17

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

Observação

Este artigo faz parte de uma série de artigos que ajudam os profissionais familiarizados com o Amazon EKS a entender o Serviço Kubernetes do Azure (AKS).

Modos de rede do Amazon EKS

Você pode usar a Amazon Virtual Private Cloud (VPC) para executar recursos da Amazon Web Services (AWS) em uma rede virtual com sub-redes públicas e privadas. As sub-redes são intervalos de endereços IP dentro da VPC. Uma sub-rede pública hospeda recursos que se conectam à Internet. Uma sub-rede privada hospeda recursos que não se conectam à 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 API pode ser acessado pela internet pública ou através da VPC. O Amazon EKS fornece várias maneiras de controlar o acesso ao endpoint 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 configuração de endpoint do cluster determina como os nós do Amazon EKS se conectam ao plano de controle gerenciado do Kubernetes. Você pode alterar as configurações do endpoint por meio do console do Amazon EKS ou da API. Para obter mais informações, consulte Controle de acesso ao ponto final do cluster Amazon EKS.

Apenas ponto de extremidade público

O modo padrão para novos clusters do Amazon EKS expõe o plano de controle por meio de um endpoint público. Quando apenas o endpoint público para o cluster está habilitado, as solicitações de API do Kubernetes originadas de dentro da VPC saem da VPC, mas não saem da rede da Amazon. Essas solicitações incluem comunicação do nó de trabalho para o plano de controle. Os nós se conectam ao plano de controle por meio de um endereço IP público e uma rota para um gateway de internet. Ou eles podem usar uma rota para um gateway NAT (conversão de endereços de rede) podendo assim usar o endereço IP público do gateway NAT.

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

Quando você habilita os endpoints públicos e privados, 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 pode ser acessado pela Internet.

Apenas ponto de extremidade privado

Ao ativar apenas o endpoint privado, todo o tráfego para o servidor da API do cluster, como os comandos kubectl ou helm, deve vir a partir da VPC do cluster ou de uma rede ligada. O acesso público ao servidor de API a partir da Internet está desativado. Para implementar esse modo de acesso, use a AWS Virtual Private Network (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.

Se você desabilitar o acesso público para o ponto de extremidade do servidor da API do Kubernetes do cluster, poderá acessar o ponto de extremidade do servidor da API do Kubernetes de uma das seguintes maneiras:

Rede conectada: Conecte sua rede à VPC usando um gateway de trânsito da AWS e, em seguida, use um computador na rede conectada. Ou você pode usar outras opções de conectividade. Verifique se o grupo de segurança do plano de controlo do Amazon EKS contém regras para permitir o tráfego de ingresso na porta 443 a partir da sua rede conectada.
Host bastião do Amazon EC2: Pode lançar uma instância do Amazon EC2 numa sub-rede pública da VPC do seu cluster. Entre nessa instância via Secure Shell (SSH) para executar kubectl comandos. Certifique-se de que o grupo de segurança do plano de controlo do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 a partir do seu host bastião. Para obter mais informações, consulte Visualizar requisitos do grupo de segurança do Amazon EKS para clusters.

Ao configurar kubectl para o host bastion, use credenciais da AWS mapeadas para a configuração de controlo de acesso baseado em funções (RBAC) do cluster. Ou você pode adicionar a entidade de segurança do AWS Identity and Access Management (IAM) que seu bastião usa à configuração do RBAC antes de remover o acesso público ao endpoint. Para obter mais informações, consulte Conceder aos usuários e funções do IAM acesso às APIs do Kubernetes e Não autorizado ou acesso negado (kubectl).
IDE do AWS Cloud9: O AWS Cloud9 é um ambiente de desenvolvimento integrado (IDE) baseado em nuvem que você pode usar para escrever, executar e depurar seu código apenas com um navegador. Você pode criar um IDE do AWS Cloud9 na VPC do cluster e usar o IDE para se comunicar com o cluster. Para obter mais informações, consulte Criar um ambiente no AWS Cloud9. Garanta que o grupo de segurança do plano de controlo do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 do grupo de segurança do IDE. Para obter mais informações, consulte Visualizar requisitos do grupo de segurança do Amazon EKS para clusters.

Ao configurar o seu IDE AWS Cloud9 em kubectl, utilize credenciais da AWS que estejam mapeadas para a configuração RBAC do seu cluster. Ou pode-se adicionar a entidade IAM que o seu IDE usa à configuração RBAC antes de remover o acesso público do ponto final. Para obter mais informações, consulte Conceder aos usuários e funções do IAM acesso às APIs do Kubernetes e Não autorizado ou acesso negado (kubectl).

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

Acesso à rede AKS ao servidor API

Para proteger o acesso à rede à API do Kubernetes no AKS, você pode usar um cluster AKS privado ou intervalos de endereços IP autorizados.

Cluster AKS privado

Um cluster AKS privado ajuda a garantir que o tráfego de rede entre o servidor de API e os nós do agente permaneça na rede virtual. Em um cluster AKS privado, o plano de controle ou servidor API tem endereços IP internos. Um cluster privado ajuda a garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça apenas na rede privada.

Em um cluster AKS privado, o servidor de API tem um endereço IP interno que só pode ser acessado por meio de um ponto de extremidade privado do Azure localizado na mesma rede virtual. As máquinas virtuais (VMs) na mesma rede virtual podem se comunicar de forma privada com o plano de controle por meio desse ponto de extremidade privado. O plano de controle ou servidor de API é hospedado na assinatura gerenciada pelo Azure. O cluster AKS e seus pools de nós estão na assinatura do cliente.

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

Descarregue 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 privada do Sistema de Nomes de Domínio (DNS). Opcionalmente, o AKS também pode criar um FQDN público que tenha um registro de endereço A correspondente na zona DNS pública do Azure. Os nós do agente utilizam o registo A na zona DNS privada para resolver o endereço IP do ponto de extremidade privado, para que comuniquem com o servidor 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. Para criar um cluster privado, você pode usar o Terraform com o Azure, Bicep, modelos do Azure Resource Manager, a CLI do Azure, o módulo do Azure PowerShell ou a API REST do Azure.

Você pode habilitar um FQDN público para o servidor de API durante o provisionamento ou usando o comando az aks update com o parâmetro --enable-public-fqdn em clusters existentes. Se você habilitar o FQDN público, as VMs que acessam o servidor deverão 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. Exemplos dessas VMs incluem um agente auto-hospedado do Azure DevOps ou um corredor auto-hospedado do GitHub Actions.

Para um cluster AKS privado, desative o FQDN público do servidor API. Para se comunicar com o plano de controle privado, uma VM deve estar na mesma rede virtual ou em uma rede virtual emparelhada que tenha 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, consulte Criar um cluster AKS privado.

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

O provedor de recursos AKS expõe os seguintes parâmetros para personalizar implantações privadas de cluster AKS:

A authorizedIpRanges cadeia de caracteres especifica intervalos de endereços IP permitidos no formato CIDR.
O disableRunCommand Boolean especifica se o run comando para o cluster deve ser desabilitado.
O enablePrivateCluster Boolean especifica se o cluster deve ser criado como privado.
O enablePrivateClusterPublicFQDN Boolean especifica se deve ser criado outro FQDN público para o cluster privado.
A privateDnsZone cadeia de caracteres 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. 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:

Opções de zona DNS privada	`enablePrivateClusterPublicFQDN: true`	`enablePrivateClusterPublicFQDN: false`
Sistema	Os nós de agente e quaisquer outras máquinas virtuais (VMs) na rede virtual do cluster AKS, ou em qualquer rede virtual conectada à zona DNS privada, utilizam o registo da zona DNS privada `A` para resolver o endereço IP privado do ponto de extremidade privado. Outras VMs usam o FQDN público do servidor de API.	Os nós de agente e quaisquer outras máquinas virtuais (VMs) na rede virtual do cluster AKS, ou em qualquer rede virtual conectada à zona DNS privada, utilizam o registo da zona DNS privada `A` para resolver o endereço IP privado do ponto de extremidade privado. Não está disponível nenhum FQDN (Nome de Domínio Totalmente Qualificado) de servidor de API público.
Nenhum	Todas as VMs, incluindo nós de agente, usam o FQDN público do servidor de API por meio de um `A` registro em uma zona DNS pública gerenciada pelo Azure.	Configuração errada. O cluster AKS privado precisa de pelo menos uma zona DNS pública ou privada para a resolução de nomes do servidor API.
O seu próprio ID de recurso de zona DNS privada	Os nós de agente e quaisquer outras máquinas virtuais (VMs) na rede virtual do cluster AKS, ou em qualquer rede virtual conectada à zona DNS privada, utilizam o registo da zona DNS privada `A` para resolver o endereço IP privado do ponto de extremidade privado. Outras VMs usam o FQDN público do servidor de API.	Os nós de agente e quaisquer outras máquinas virtuais (VMs) na rede virtual do cluster AKS, ou em qualquer rede virtual conectada à zona DNS privada, utilizam o registo da zona DNS privada `A` para resolver o endereço IP privado do ponto de extremidade privado. Não está disponível nenhum FQDN (Nome de Domínio Totalmente Qualificado) de servidor de API público.

Conectividade e gerenciamento de cluster privado

Em um cluster AKS privado, o ponto de extremidade do servidor de API não tem endereço IP público. Você pode usar uma das seguintes opções para estabelecer conectividade de rede com o cluster privado:

Crie uma VM na mesma rede virtual do cluster AKS, usando o comando az vm create com o parâmetro --vnet-name.
Use uma VM em uma rede virtual separada e configure o emparelhamento de rede virtual com a rede virtual de cluster AKS.
Configure um Azure ExpressRoute ou um gateway VPN para se conectar à rede virtual do cluster.
Crie uma conexão de ponto de extremidade privado do Azure dentro de outra rede virtual.
Use uma instância do Azure Cloud Shell implantada em uma sub-rede conectada ao servidor de API do cluster.

Use a CLI do Azure para executar o comando az aks invoke para acessar clusters privados sem configurar um gateway VPN ou ExpressRoute. Use este comando para invocar remotamente outros comandos, como kubectl e helm, em seu cluster privado por meio da API do Azure, sem se conectar diretamente ao cluster. Para usar command invoke, configure as permissões necessárias para as ações Microsoft.ContainerService/managedClusters/runcommand/action e Microsoft.ContainerService/managedclusters/commandResults/read.

No portal do Azure, você pode usar o Run command recurso para executar comandos em seu cluster privado. Esse recurso emprega a command invoke funcionalidade para executar comandos no cluster. O pod que o Run command recurso cria fornece kubectl e helm ferramentas para gerenciar seu cluster. O Run command também fornece um ambiente Bash dentro do pod que inclui ferramentas como jq, xargs, grep, e awk.

Você pode usar o Azure Bastion na mesma rede virtual ou numa rede virtual emparelhada para se conectar a uma VM de gestão intermediária. O Azure Bastion é uma plataforma como serviço (PaaS) totalmente gerenciada que você pode usar para se conectar a uma VM por meio do navegador e do portal do Azure. O Azure Bastion fornece conectividade de Protocolo de Área de Trabalho Remota (RDP) ou VM SSH altamente segura e contínua 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.

Integração de Servidor API na VNet

Um cluster AKS configurado com a Integração de VNet do Servidor de API projeta o ponto de extremidade do servidor de API diretamente em uma sub-rede delegada. A sub-rede está na rede virtual onde o AKS está implantado. A integração de VNet do API Server permite a comunicação de rede entre o servidor de API e os nós do cluster, sem um link privado ou túnel. O servidor de API está disponível atrás de um VIP de balanceador de carga interno que está na sub-rede delegada. Os nós são configurados para usar o balanceador de carga interno VIP. Use a integração de VNet do API Server para garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça apenas na rede privada.

O plano de controle ou o servidor de API está em uma assinatura do Azure gerenciada pelo AKS. Seu cluster ou pool de nós está em sua assinatura do Azure. O servidor e as VMs que compõem os nós do cluster podem se comunicar entre si por meio dos endereços IP VIP e pod do servidor de API projetados na sub-rede delegada.

Você pode usar a integração de VNet do API Server com clusters públicos e privados. Você pode adicionar ou remover o acesso público após o provisionamento do cluster. Ao contrário dos clusters que não têm integração de rede virtual, os nós do agente sempre se comunicam diretamente com o endereço IP privado do IP do balanceador de carga interno do servidor de API sem usar DNS. O tráfego que vai do nó para o servidor de API está na rede privada. Além disso, a conectividade do servidor ao nó da API não requer um túnel. Os clientes fora do cluster podem se comunicar com o servidor de API normalmente se o acesso à rede pública estiver habilitado. Se o acesso à rede pública estiver desativado, siga a mesma metodologia de configuração de DNS privado que os clusters privados padrão. Para obter mais informações, consulte Criar um cluster AKS com integração de VNet do API Server.

Intervalos de endereços IP autorizados

Você também pode usar intervalos de endereços IP autorizados para melhorar a segurança do cluster e minimizar os ataques ao servidor de API. Os intervalos de endereços IP 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.

O seguinte az aks update comando da CLI do Azure autoriza intervalos de endereços 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

Considere os seguintes pontos-chave para a conectividade AKS:

Um cluster privado AKS oferece segurança e isolamento aprimorados em comparação com intervalos de endereços IP autorizados. No entanto, não é possível converter um cluster AKS público existente em um cluster privado. Em vez disso, você pode habilitar intervalos de endereços IP autorizados para qualquer cluster AKS existente.
Não é possível aplicar intervalos de endereços IP autorizados a um ponto de extremidade de servidor de API privado. Eles só se aplicam ao servidor de API público.
Os clusters privados não suportam agentes hospedados pelo Azure DevOps. Em vez disso, deve usar agentes autogeridos.
Para que o Registro de Contêiner do Azure funcione com um cluster AKS privado, você deve configurar um link privado para o registro de contêiner na rede virtual do cluster. Como alternativa, pode-se estabelecer emparelhamento entre a rede virtual do Registo de Contentores e a rede virtual do cluster privado.
As limitações do Azure Private Link aplicam-se a clusters privados.
Se o ponto de extremidade privado na sub-rede do cliente de um cluster privado for excluído ou modificado, o cluster para de funcionar.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

Paolo Salvatori | Engenheiro de Serviço Principal
Martin Gjoshevski | Engenheiro de Serviços Sénior
Laura Nicolas | Arquiteto de Soluções Cloud Sênior

Outros contribuidores:

Chad Kittel | Engenheiro de Software Principal - Azure Patterns & Practices
Ed Price | Gerente de Programa de Conteúdo Senior
Theano Petersen | Redator Técnico

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.