Acesso seguro de rede ao Kubernetes

Este artigo compara os modos de rede do Serviço de Kubernetes do Azure (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 do 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 ponto de extremidade permite configurar se o ponto de extremidade do Servidor de API pode ser acessado pela Internet pública ou pela 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 de Roteamento de domínio interno sem classe (CIDR) 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 gerenciado do Kubernetes é determinada por qual configuração de ponto de extremidade é configurada para o cluster. Você pode alterar as configurações de ponto de extremidade a qualquer momento por meio do console do Amazon EKS ou da API. Para obter mais informações, veja Controle de acesso aos pontos de extremidade do cluster do Amazon EKS.

Somente ponto de extremidade público

Expor o plano de controle por meio de um ponto de extremidade público é o modo padrão para novos clusters do Amazon EKS. Quando apenas o ponto de extremidade 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 avião, saem da VPC, mas não 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 um gateway da conversão de endereço de rede (NAT) onde possam usar o endereço IP público do gateway da NAT.

Pontos de extremidade públicos e privados

Quando os pontos de extremidade públicos e privados 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 (ENI) 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 estiver habilitado, todo o tráfego para o servidor de API do cluster, como comandos kubectl ou helm, deverá vir de dentro do VPC do cluster ou de uma rede conectada . O acesso público ao servidor da API a partir da Internet está desabilitado. Você pode implementar esse modo de acesso usando a rede privada virtual do AWS (AWS VPN) ou o AWS DirectConnect na VPC. Para restringir o acesso ao ponto de extremidade sem AWS VPN ou DirectConnect, você pode adicionar restrições CIDR ao ponto de extremidade público para limitar as conexões sem configurar mais rede.

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

• de rede conectada: conecte sua rede ao VPC com um gateway de trânsito AWS ou outras opções de conectividade e use um computador na rede conectada. Você deve garantir que o grupo de segurança do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 da rede conectada.
• host de bastiões do Amazon EC2: você pode iniciar uma instância do Amazon EC2 em uma sub-rede pública no VPC do cluster e fazer logon por meio do SSH nessa instância para executar comandos kubectl. Para obter mais informações, consulte hosts de bastion do Linux no AWS. Você deve garantir que o grupo de segurança do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 do seu host de bastião. Para obter mais informações, consulte Exibir os requisitos do grupo de segurança do Amazon EKS para clusters. Ao configurar kubectl para seu host de bastiões, use as credenciais do AWS que já estão mapeadas para a configuração rbac do cluster ou adicione a entidade de segurança do IAM que o bastião usará para a configuração do RBAC antes de remover o acesso público do ponto de extremidade. Para obter mais informações, consulte Conceder acesso a usuários e funções do IAM às APIs do Kubernetes e não autorizado ou de acesso negado (kubectl).
• IDE do AWS Cloud9: o AWS Cloud9 é um IDE (ambiente de desenvolvimento integrado) baseado em nuvem que permite que você escreva, execute e depure seu código apenas com um navegador. Você pode criar um IDE do AWS Cloud9 no VPC do cluster e usar o IDE para se comunicar com o cluster. Para obter mais informações, consulte Criando um ambiente no AWS Cloud9. Você deve garantir que o grupo de segurança do plano de controle 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 Exibir os requisitos do grupo de segurança do Amazon EKS para clusters. Ao configurar kubectl para o IDE do AWS Cloud9, use as credenciais do AWS que já estão mapeadas para a configuração RBAC do cluster ou adicione a entidade de segurança do IAM que o IDE usará à configuração do RBAC antes de remover o acesso público do ponto de extremidade. Para obter mais informações, consulte Conceder acesso a usuários e funções do IAM às APIs do Kubernetes e não autorizado ou de acesso negado (kubectl).

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

Acesso de rede do AKS ao servidor de API

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

Cluster do AKS particular

Um cluster privado do AKS 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 privado do AKS, o plano de controle ou o servidor de API tem endereços IP internos definidos no documento RFC1918 - Alocação de Endereço para Internet Privada. 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 privado do AKS, 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. Qualquer VM (máquina virtual) na mesma rede virtual pode se comunicar privadamente com o plano de controle por meio desse ponto de extremidade privado. O plano de controle ou o servidor de API é hospedado na assinatura gerenciada pelo Azure, enquanto o cluster do AKS e seus pools de nós estão na assinatura do cliente.

Quando você provisiona um cluster privado do AKS, 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 do AKS privado.

Baixe um Arquivo Visio dessa arquitetura.

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

O provedor de recursos do AKS pode criar a zona do DNS privado no grupo de recursos do nó ou você pode criar a zona do DNS privado e enviar sua 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 PowerShell do Azure 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 parâmetro --enable-public-fqdn em clusters existentes. Se você habilitar o FQDN público, qualquer VM que acessar o servidor, como um agente auto-hospedado do Azure DevOps ou um executor auto-hospedado do GitHub Actions, deverá estar na mesma rede virtual que hospeda o cluster ou em uma rede conectada via emparelhamento de rede virtual ou VPN site a site.

Para um cluster do AKS privado, desabilite 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 do DNS privado. O registro A na zona do DNS privado resolve o FQDN do servidor de API para o endereço IP de ponto de extremidade privado que se comunica com o plano de controle subjacente. Para obter mais informações, consulte Criar um cluster particular do Serviço de Kubernetes do Azure.

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

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

• authorizedIpRanges (string) especifica intervalos de IP permitidos no formato CIDR.
• disableRunCommand (booleano) especifica se o comando run deve ou não ser desabilitado para o cluster.
• enablePrivateCluster (booleano) especifica se o cluster deve ou não ser criado como privado.
• enablePrivateClusterPublicFQDN (booleano) especifica se deve ou não criar outro FQDN público para o cluster privado.
• privateDnsZone (string) especifica uma zona do DNS privado no grupo de recursos do nó. Se você não especificar um valor, o provedor de recursos criará a zona. É possível especificar os seguintes valores:
  • System é o valor padrão.
  • None usa como padrão o DNS público, portanto, o AKS não cria uma zona do DNS privado.
  • <Your own private DNS zone resource ID> usa uma zona do DNS privado criada 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 do AKS privado:

Conectividade e gerenciamento de cluster privado

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

1. Crie uma máquina virtual na mesma rede virtual que o cluster do 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 do cluster do AKS.
3. Configure um Azure ExpressRoute ou VPN para se conectar à rede virtual do cluster.
4. Crie uma conexão ponto de extremidade privado do Azure dentro de outra rede virtual.
5. Use uma instância do Cloud Shell implantada em uma sub-rede conectada ao servidor de API para o cluster.

Usando a CLI do Azure, você pode usar o comando az aks invoke comando para acessar clusters privados sem a necessidade de configurar uma VPN ou Uma Rota Expressa. Esse comando permite que você invoque comandos remotamente, como kubectl e helm, em seu cluster privado por meio da API do Azure, sem precisar se conectar diretamente ao cluster. Para usar command invoke, você precisa ter as permissões necessárias configuradas para as ações de 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 de kubectl e helm para gerenciar seu cluster. Além disso, ele dá suporte ao 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 jump box. 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 de protocolo RDP ou SSH (Secure Shell) por TLS, 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, nem de um agente e tampouco de um software cliente especial.

Integração de VNet do Servidor de API

Um cluster do AKS (Serviço de Kubernetes do Azure) configurado com integração VNet do Servidor de API projeta o ponto de extremidade do servidor de API diretamente em uma sub-rede delegada na VNet em que o AKS é implantado. A Integração VNet do Servidor de API permite a comunicação de rede entre o servidor de API e os nós de cluster sem a necessidade de um link ou túnel privado. O servidor de API está disponível por trás de um VIP do balanceador de carga interno na sub-rede delegada, que os nós estão configurados para utilizar. Usando a Integração 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 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 de cluster podem se comunicar entre si por meio do VIP do servidor de API e dos IPs de pod projetados na sub-rede delegada.

A Integração VNet do Servidor de API tem suporte 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 nó para o tráfego do servidor de API é mantido em rede privada e nenhum túnel é necessário para que o servidor de API node conectividade. Clientes fora do cluster que precisam se comunicar com o servidor de API podem fazer isso 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 privados de padrão. Para obter mais informações, consulte Criar um cluster do Serviço de Kubernetes do Azure com ode Integração 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 do 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, confira Proteger acesso ao servidor de API usando intervalos de endereços IP autorizados no AKS (Serviço de Kubernetes do Azure).

O seguinte comando az aks update 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 do AKS, há várias considerações importantes a serem consideradas. Aqui estão alguns pontos importantes a serem informados:

• Um cluster privado do 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 habilitados para qualquer cluster do AKS existente.
• Os intervalos de IP autorizados não podem ser aplicados a um ponto de extremidade de servidor de API privada. Elas se aplicam apenas ao servidor de API público.
• Os clusters privados não dão suporte a agentes hospedados no Azure DevOps. Em vez disso, é recomendável usar agentes auto-hospedados.
• Para que o Registro de Contêiner do Azure funcione com um cluster do 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 de Link Privado do Azure se aplicam 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.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Paolo Salvatori | Engenheiro principal de serviço
• Martin Gjoshevski | Engenheiro sênior de serviços
• Laura Nicolas | Arquiteto sênior de soluções de nuvem

Outros colaboradores:

• Chad Kittel | Engenheiro de Software Principal
• Ed Price | Gerente sênior de programa de conteúdo
• Theano Petersen | Escritor técnico

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

Próximas etapas

• AKS para profissionais do Amazon EKS
• Gerenciamento de acesso e identidade do Kubernetes
• Monitoramento e registro em log do Kubernetes
• Opções de armazenamento para um cluster do Kubernetes
• Gerenciamento 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 documentação e exemplos de automação para implantar clusters do AKS com uma API segura:

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