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 comandos kubectl ou helm, 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.

Se você tiver desabilitado 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 com um gateway de trânsito da AWS ou outras opções de conectividade e use um computador na rede conectada. Você deve garantir que o security group do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 da rede conectada.
• de host bastião do Amazon EC2: você pode executar uma instância do Amazon EC2 em uma sub-rede pública na VPC do cluster e, em seguida, fazer login via SSH nessa instância para executar comandos kubectl. Para obter mais informações, consulte hosts bastion Linux no AWS. Você deve garantir que o security group do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 do host bastion. Para obter mais informações, consulte Visualizar requisitos do grupo de segurança do Amazon EKS para clusters. Ao configurar o kubectl para seu host bastion, certifique-se de usar credenciais da AWS que já estão mapeadas para a configuração RBAC do cluster ou adicione o principal do IAM que seu bastion usará à 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 permite escrever, executar e depurar seu código com apenas 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 Criação de um ambiente no AWS Cloud9. Você deve garantir que o security group do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 do security group do IDE. Para obter mais informações, consulte Visualizar requisitos do grupo de segurança do Amazon EKS para clusters. Ao configurar o kubectl para seu IDE do AWS Cloud9, certifique-se de usar credenciais da AWS que já estão mapeadas para a configuração RBAC do cluster ou adicione o principal do IAM que seu IDE usará à 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).

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 AKS privado garante que o tráfego de rede entre o servidor de API e os nós do agente permaneça dentro da rede virtual. Em um cluster 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 um cluster privado, você pode 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ó é 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 desse 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.

Quando você provisiona um cluster 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 A na zona DNS privada para resolver o endereço IP privado do ponto de extremidade privado para comunicação com o servidor de API.

O diagrama a seguir ilustra uma configuração de cluster AKS 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

Em um cluster AKS privado, o ponto de extremidade do servidor de API não tem endereço IP público. Existem várias opções para estabelecer conectividade de rede com o cluster privado:

1. Crie uma máquina virtual na mesma rede virtual que o cluster AKS usando o comando az vm create com o sinalizador --vnet-name.
2. Use uma máquina virtual em uma rede virtual separada e configure de emparelhamento de rede virtual com a rede virtual de cluster AKS.
3. Configure um Azure ExpressRoute ou VPN para se conectar à rede virtual do cluster.
4. Crie uma conexão Azure Private Endpoint dentro de outra rede virtual.
5. Use uma instância do Cloud Shell implantada em uma sub-rede conectada ao servidor de API do cluster.

Usando a CLI do Azure, você pode usar o comando az aks invoke para acessar clusters privados sem a necessidade de configurar uma VPN ou Rota Expressa. Este comando permite-lhe invocar remotamente comandos, como kubectl e helm, no seu cluster privado através da API do Azure, sem ter de se ligar diretamente ao cluster. Para usar command invoke, você precisa ter as permissões necessárias configuradas para as ações Microsoft.ContainerService/managedClusters/runcommand/action e Microsoft.ContainerService/managedclusters/commandResults/read.

No portal do Azure, você pode utilizar o recurso Run command para executar comandos em seu cluster privado. Esse recurso realmente utiliza a funcionalidade command invoke para executar comandos em seu cluster. O pod criado pelo recurso Run command fornece ferramentas kubectl e helm para gerenciar seu cluster. Além disso, ele suporta Bash com ferramentas como jq, xargs, grepe awk disponíveis.

Você pode usar do Azure Bastion na mesma rede virtual ou em uma rede virtual emparelhada para se conectar a uma máquina virtual de gerenciamento de caixa de salto. 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.

Integração de VNet do Servidor de API

Um cluster do Serviço Kubernetes do Azure (AKS) configurado com Integração de VNet do Servidor de API projeta o ponto de extremidade do servidor de API diretamente em uma sub-rede delegada na rede virtual onde o AKS é implantado. 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. O servidor de API está disponível atrás de um VIP de balanceador de carga interno na sub-rede delegada, que os nós estão configurados para utilizar. Usando a Integração de VNet do Servidor de API, você pode 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 máquinas virtuais que compõem os nós do cluster podem se comunicar entre si por meio dos IPs VIP e pod do servidor de API projetados na sub-rede delegada.

A integração de VNet do API Server é suportada para clusters públicos ou privados. Você pode adicionar ou remover o acesso público após o provisionamento do cluster. Ao contrário dos clusters integrados não VNet, os nós do agente sempre se comunicam diretamente com o endereço IP privado do IP do ILB (balanceador de carga interno) do servidor de API sem usar DNS. Todo o tráfego de nó para servidor de API é mantido em rede privada e nenhum túnel é necessário para a conectividade do servidor de API para o nó. Os clientes fora do cluster que precisam se comunicar com o servidor de API podem fazê-lo normalmente se o acesso à rede pública estiver habilitado. Se o acesso à rede pública estiver desabilitado, você deverá seguir a mesma metodologia de configuração de DNS privado que os clusters padrão privados. Para obter mais informações, consulte Criar um cluster do Serviço Kubernetes do Azure com a integração de VNet do Servidor de API.

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

Ao considerar a conectividade AKS, há várias considerações importantes a ter em mente. Aqui estão alguns pontos-chave a ter em conta:

• Um cluster privado AKS oferece segurança e isolamento aprimorados em comparação com IPs autorizados. No entanto, não é possível converter um cluster AKS público existente em um cluster privado. Em vez disso, os IPs autorizados podem ser ativados para qualquer cluster AKS existente.
• Os intervalos de IP autorizados não podem ser aplicados 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 dão suporte a agentes hospedados pelo Azure DevOps. Em vez disso, recomenda-se o uso de agentes auto-hospedados.
• Para que o Registro de Contêiner do Azure funcione com um cluster AKS privado, um link privado deve ser configurado para o registro de contêiner na rede virtual do cluster. Como alternativa, o emparelhamento pode ser estabelecido 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 o ponto de extremidade privado na sub-rede do cliente de um cluster privado for excluído ou modificado, 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 | Arquiteto de Soluções Cloud 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