Proteger o acesso de rede ao Kubernetes

Este artigo compara os modos de rede para Azure Kubernetes Service (AKS) e o Amazon Elastic Kubernetes Service (Amazon EKS). O artigo descreve como melhorar a segurança da ligação ao servidor de API gerida 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), pode lançar recursos do Amazon Web Services (AWS) numa rede virtual composta por sub-redes públicas e privadas ou intervalos de endereços IP no VPC. Uma sub-rede pública aloja recursos que têm de estar ligados à Internet e uma sub-rede privada aloja recursos que não estão ligados à Internet pública. O Amazon EKS pode aprovisionar grupos de nós geridos em sub-redes públicas e privadas.

O controlo de acesso a pontos finais permite-lhe configurar se o ponto final do Servidor de API está acessível a partir da Internet pública ou através do VPC. O EKS fornece várias formas de controlar o acesso ao ponto final do cluster. Pode ativar o ponto final público predefinido, um ponto final privado ou ambos os pontos finais em simultâneo. Quando ativa o ponto final público, pode adicionar restrições de Encaminhamento de Inter-Domain Sem Classe (CIDR) para limitar os endereços IP do cliente que podem ligar ao ponto final público.

A forma como os nós do Amazon EKS se ligam ao plano de controlo do Kubernetes gerido é determinada pela definição de ponto final configurada para o cluster. Pode alterar as definições de ponto final em qualquer altura através da consola do Amazon EKS ou da API. Para obter mais informações, veja Amazon EKS cluster endpoint access control (Controlo de acesso a pontos finais de cluster do Amazon EKS).

Apenas ponto final público

Expor o plano de controlo através de um ponto final público é o modo predefinido para novos clusters do Amazon EKS. Quando apenas o ponto final público do cluster está ativado, os pedidos da API do Kubernetes provenientes do Amazon VPC, como o nó de trabalho para controlar a comunicação do plano, deixam o VPC mas não saem da rede da Amazon. Para que os nós se liguem ao plano de controlo, têm de utilizar um endereço IP público e uma rota para um gateway de Internet ou uma rota para um gateway de tradução de endereços de rede (NAT), onde podem utilizar o endereço IP público do NAT Gateway.

Pontos finais públicos e privados

Quando os pontos finais públicos e privados estão ativados, os pedidos da API do Kubernetes a partir do VPC comunicam com o plano de controlo através das Interfaces de Rede Elástica (ENIs) geridas pelo Amazon EKS no VPC. O servidor de API do cluster está acessível a partir da Internet.

Apenas ponto final privado

Quando apenas o ponto final privado está ativado, todo o tráfego para o servidor de API de cluster, como kubectl ou helm comandos, tem de ser proveniente do VPC do cluster ou de uma rede ligada. O acesso público ao servidor de API a partir da Internet está desativado. Pode implementar este modo de acesso com a Rede Privada Virtual (VPN do AWS) do AWS ou o AWS DirectConnect para o VPC. Para restringir o acesso ao ponto final sem a VPN do AWS ou o DirectConnect, pode adicionar restrições CIDR ao ponto final público para limitar as ligações sem configurar mais redes.

Para obter mais informações sobre as opções de conectividade, veja Aceder a um Servidor de API Apenas Privado.

Acesso de rede do AKS ao servidor de API

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

Cluster privado do AKS

Um cluster privado do AKS garante que o tráfego de rede entre o servidor de API e os conjuntos de nós permanece na rede virtual. Num cluster privado do AKS, o plano de controlo ou o servidor de API tem um endereço IP interno que só é acessível através de um ponto final privado do Azure localizado na mesma rede virtual. Qualquer máquina virtual (VM) na mesma rede virtual pode comunicar em privado com o plano de controlo através do ponto final privado. O plano de controlo ou o servidor de API está alojado na subscrição gerida pelo Azure, enquanto o cluster do AKS e os respetivos conjuntos de nós estão na subscrição do cliente.

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

Transfira um ficheiro do Visio desta arquitetura.

Para aprovisionar um cluster privado do AKS, o fornecedor de recursos do AKS cria um nome de domínio privado completamente qualificado (FQDN) para o grupo de recursos de nós numa zona DNS privada. Opcionalmente, o AKS também pode criar um FQDN público com um registo de endereço (A) correspondente na zona DNS pública do Azure. Os nós do agente utilizam o A registo na zona DNS privada para resolver o endereço IP do ponto final privado para comunicação com o servidor de API.

O fornecedor de recursos do AKS pode criar a zona DNS privada no grupo de recursos do nó ou pode criar a zona DNS privada e transmitir o respetivo ID de recurso para o sistema de aprovisionamento. Pode criar um cluster privado quando utiliza o Terraform com o Azure, Bicep, modelos arm, CLI do Azure, módulo Azure PowerShell ou API REST do Azure para criar o cluster.

Pode ativar um FQDN público para o servidor de API durante o aprovisionamento ou ao utilizar o comando az aks update com o --enable-public-fqdn parâmetro em clusters existentes. Se ativar o FQDN público, qualquer VM que aceda ao servidor, como um agente autoalojado do Azure DevOps ou um GitHub Actions autoalojado, tem de estar na mesma rede virtual que aloja o cluster ou numa rede ligada através do peering de rede virtual ou da VPN site a site.

Para um cluster privado do AKS, desativa o FQDN público do servidor de API. Para comunicar com o plano de controlo privado, uma VM tem de estar na mesma rede virtual ou numa rede virtual em modo de peering com uma ligação de rede virtual para a zona DNS privada. O A registo na zona DNS privado resolve o FQDN do servidor de API para o endereço IP de ponto final privado que comunica com o plano de controlo subjacente. Para obter mais informações, veja Criar um cluster do Azure Kubernetes Service privado.

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

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

• authorizedIpRanges (cadeia) especifica intervalos IP permitidos no formato CIDR.
• disableRunCommand (booleano) especifica se pretende ou não desativar o run comando do cluster.
• enablePrivateCluster (booleano) especifica se pretende ou não criar o cluster como privado.
• enablePrivateClusterPublicFQDN (booleano) especifica se pretende ou não criar outro FQDN público para o cluster privado.
• privateDnsZone (cadeia) especifica uma zona DNS privada no grupo de recursos do nó. Se não especificar um valor, o fornecedor de recursos cria a zona. Pode especificar os seguintes valores:
  • System é o valor predefinido.
  • None o DNS público é predefinido, pelo que o AKS não cria uma zona DNS privada.
  • <Your own private DNS zone resource ID> utiliza uma zona DNS privada que criar no formato privatelink.<region>.azmk8s.io ou <subzone>.privatelink.<region>.azmk8s.io.

A tabela seguinte mostra as opções de configuração do DNS para implementar um cluster privado do AKS:

Conectividade e gestão de clusters privados

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

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

• Utilize VMs numa rede virtual separada e configure o peering de rede virtual com a rede virtual do cluster do AKS.

• Utilize uma ligação do Azure ExpressRoute ou VPN .

• Utilize o comando az aks do comando az aks da CLI do Azure para executar kubectl e helm comandos no cluster privado sem ligar diretamente ao cluster.

• Utilize uma ligação do Ponto Final Privado do Azure .

Pode gerir um cluster privado do AKS com a ferramenta de linha de comandos kubectl a partir de uma VM de gestão na mesma rede virtual ou numa rede virtual em modo de peering.

Pode utilizar o Azure Bastion na mesma rede virtual ou numa rede virtual em modo de peering para ligar a uma VM de gestão de jumpbox. O Azure Bastion é uma plataforma como um serviço (PaaS) totalmente gerida que lhe permite ligar a uma VM com o browser e o portal do Azure. O Azure Bastion fornece conectividade segura e totalmente integrada do protocolo de ambiente de trabalho remoto (RDP) ou da shell segura (SSH) através da segurança da camada de transporte (TLS) diretamente a partir do portal do Azure. Quando as VMs se ligam através do Azure Bastion, não precisam de um endereço IP público, agente ou software de cliente especial.

Também pode utilizar az aks command invoke para executar kubectl ou helm comandos no cluster privado do AKS sem ter de se ligar 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 é utilizar intervalos de IP autorizados. Os IPs autorizados restringem o acesso ao plano de controlo de um cluster do AKS público a uma lista conhecida de endereços IP e CIDRs. Quando utiliza esta opção, o servidor de API ainda está exposto publicamente, mas o acesso é limitado. Para obter mais informações, veja Acesso seguro ao servidor de API com intervalos de endereços IP autorizados no Azure Kubernetes Service (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 de conectividade do AKS

• Um cluster privado do AKS fornece maior segurança e isolamento do que os IPs autorizados. No entanto, não pode converter um cluster do AKS público existente num cluster privado. Pode ativar IPs autorizados para qualquer cluster do AKS existente.

• Não pode aplicar intervalos de IP autorizados a um ponto final privado do servidor de API. Os IPs autorizados aplicam-se apenas ao servidor de API público.

• Os clusters privados não suportam agentes alojados no Azure DevOps. Considere utilizar agentes autoalojados.

• Para permitir que Azure Container Registry funcionem com um cluster privado do AKS, configure uma ligação privada para o registo de contentor na rede virtual do cluster. Em alternativa, configure o peering entre a rede virtual do Container Registry e a rede virtual do cluster privado.

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

• Se eliminar ou modificar o ponto final 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 contribuintes.

Autores principais:

• Paolo Salvatori | Engenheiro de Serviço Principal
• Martin Gjoshevski | Engenheiro de Serviço Sénior
• Laura Nicolas | Engenheiro de Software Sénior

Outros contribuidores:

• Chad Kittel | Engenheiro de Software Principal
• Preço Ed | Gestor de Programas de Conteúdo Sénior
• Theano Petersen | Escritor Técnico

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

Passos seguintes

• AKS para profissionais do Amazon EKS
• Gestão de identidades e acessos do Kubernetes
• Monitorização e registo do Kubernetes
• Opções de armazenamento para um cluster do Kubernetes
• Gestão de custos do Kubernetes
• Gestão de conjuntos de nós e nós do Kubernetes
• Governação do cluster

Recursos relacionados

As seguintes referências fornecem ligações para exemplos de documentação e automatização para implementar clusters do AKS com uma API segura:

• Criar um cluster do AKS Privado com uma Zona DNS Pública
• Criar um cluster de Azure Kubernetes Service privado com o Terraform e o Azure DevOps
• Criar um cluster de Azure Kubernetes Service público ou privado com o NAT Gateway do Azure e Gateway de Aplicação do Azure
• Utilizar Pontos Finais Privados com um Cluster do AKS Privado
• Introdução ao Azure Private Link
• Introdução à Infraestrutura de Rede Segura com segurança de rede do Azure