Melhores práticas para conectividade e segurança de rede no Azure Kubernetes Service (AKS)

Ao criar e gerir clusters no Azure Kubernetes Service (AKS), fornece conectividade de rede para os seus nós e aplicações. Esses recursos de rede incluem intervalos de endereços IP, balanceadores de carga e controladores de entrada.

Este artigo de práticas recomendadas se concentra na conectividade de rede e na segurança para operadores de cluster. Neste artigo, você aprenderá a:

Escolha o modelo de rede apropriado

Orientações sobre boas práticas

Use o Azure CNI Overlay para a maioria dos cenários. Se as cargas de trabalho exigirem acesso direto ao IP do pod a partir de redes ligadas, utilize uma rede plana com o Azure CNI Pod Subnet.

As redes virtuais fornecem a conectividade básica para os nós AKS e os clientes acederem aos seus aplicativos. Há duas maneiras diferentes de implantar clusters AKS em redes virtuais:

• Rede de sobreposição: o Azure CNI Overlay atribui endereços IP dos pods a partir de um CIDR de pods separado. O tráfego que sai do cluster é convertido para o endereço IP do nó, e os pods não são diretamente acessíveis através dos seus endereços IP privados a partir de redes conectadas.
• Rede plana: o Azure CNI Pod Subnet ou o Azure CNI Node Subnet legado atribuem endereços IP aos pods a partir do espaço da rede virtual. Os pods podem ser acedidos pelos seus endereços IP privados a partir de redes ligadas.

Para mais informações sobre como selecionar um modelo de rede, consulte Planear a rede de pods para o AKS.

Visão geral do Azure CNI networking

O Azure CNI fornece gestão de endereços IP (IPAM) e conectividade para pods e nós. A opção IPAM é separada do plano de dados da rede. Por exemplo, pode usar o Azure CNI alimentado pela Cilium com Azure CNI Overlay ou uma opção de rede plana.

O diagrama seguinte mostra dois nós AKS, cada um ligado através de uma ponte de rede a uma rede virtual Azure partilhada.

A rede CNI do Azure permite a separação do controlo e gestão dos recursos. Do ponto de vista da segurança, muitas vezes você deseja que equipes diferentes gerenciem e protejam esses recursos. As características de conectividade dependem do modelo de rede. Os pods de sobreposição iniciam ligações à rede virtual e aos recursos locais através do endereço IP do nó. Os pods de rede plana podem comunicar diretamente com recursos conectados através dos seus endereços IP privados.

Quando usa rede Azure CNI, o recurso de rede virtual está num grupo de recursos separado do cluster AKS. Delegue permissões para a identidade do cluster AKS para acessar e gerenciar esses recursos. A identidade do cluster usada pelo cluster AKS deve ter pelo menos permissões de Colaborador de Rede na sub-rede da sua rede virtual.

Se você deseja definir uma função personalizada em vez de usar a função interna de Colaborador de Rede, as seguintes permissões são necessárias:

Por padrão, o AKS usa uma identidade gerenciada para sua identidade de cluster. No entanto, você pode usar um service principal.

• Para mais informações sobre a delegação do principal de serviço do AKS, consulte Delegar acesso a outros recursos do Azure.
• Para obter mais informações sobre identidades gerenciadas, consulte Usar identidades gerenciadas.

Planeie intervalos de endereços com base no modelo de rede. Tenha em mente os seguintes critérios:

• Com o Azure CNI Overlay, dimensione a sub-rede dos nós e utilize um CIDR privado separado para os pods. Cada nó recebe um /24 espaço de endereçamento do pod CIDR.
• Numa rede plana, dimensione as sub-redes da rede virtual para os nós e para os pods. A sub-rede CNI Pod do Azure utiliza subredes de nó e pod separadas, enquanto a sub-rede legada CNI do Azure utiliza uma sub-rede para ambas.
• Evite usar intervalos de endereços IP que se sobrepõem aos recursos de rede existentes.
  • É necessário permitir conectividade a redes no local ou emparelhadas na Azure.
• Para lidar com eventos de escalonamento ou atualizações de clusters, deve ter endereços IP adicionais disponíveis na sub-rede atribuída.
  • Este espaço de endereçamento extra é especialmente importante se usar contêineres do Windows Server, pois esses grupos de nós requerem uma atualização para aplicar as atualizações de segurança mais recentes. Para mais informações sobre os nós do Windows Server, consulte Atualize um pool de nós no AKS.

Para calcular o espaço de endereçamento IP necessário, consulte o planeamento de endereços IP para clusters AKS.

Ao criar um cluster com a rede Azure CNI, especifica outros intervalos de endereços para o cluster, como o IP do serviço DNS e o intervalo de endereços do serviço. De um modo geral, certifique-se de que estes intervalos de endereços não se sobrepõem entre si nem a quaisquer redes associadas ao cluster, incluindo redes virtuais, sub-redes, redes locais e redes peered.

Para detalhes sobre modelos de rede, limites e dimensionamento de endereços, consulte Azure CNI networking overview.

Distribuir tráfego de entrada

Orientações sobre boas práticas

Para distribuir tráfego HTTP ou HTTPS para seus aplicativos, use recursos de entrada e controladores. Comparados com um balanceador de carga Azure, os controladores de entrada oferecem funcionalidades extra e podem ser geridos como recursos nativos Kubernetes.

Embora um balanceador de carga Azure possa distribuir o tráfego dos clientes para aplicações no seu cluster AKS, é limitado na compreensão desse tráfego. Um recurso de balanceador de carga funciona na camada 4 e distribui o tráfego com base no protocolo ou nas portas.

A maioria dos aplicativos Web que usam HTTP ou HTTPS deve usar recursos e controladores de entrada do Kubernetes, que funcionam na camada 7. O Ingress pode distribuir o tráfego com base na URL do aplicativo e lidar com a terminação TLS/SSL. O Ingress também reduz o número de endereços IP que se expõem e mapeiam.

Com um balanceador de carga, cada aplicativo normalmente precisa de um endereço IP público atribuído e mapeado para o serviço no cluster AKS. Com um recurso de entrada, um único endereço IP pode distribuir o tráfego para vários aplicativos.

O diagrama mostra um único endereço IP público a receber tráfego externo e um controlador de entrada a distribuir esse tráfego para múltiplos serviços no cluster AKS.

O Ingress tem dois componentes: um recurso de entrada e um controlador de entrada.

Recurso de Ingress

O recurso Ingress é um manifesto YAML de kind: Ingress. Ele define o host, os certificados e as regras para rotear o tráfego para os serviços em execução no cluster AKS.

O seguinte manifesto YAML de exemplo utiliza a classe NGINX Ingress gerida do complemento de encaminhamento de aplicações. Distribui tráfego para myapp.com para um de dois serviços, blogservice ou storeservice, e direciona o cliente para um ou outro serviço com base no URL a que acede.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

O ingressClassName campo seleciona a classe de entrada e deve corresponder a uma classe configurada num controlador de entrada no cluster. O valor webapprouting.kubernetes.azure.com seleciona o controlador de entrada NGINX gerido fornecido pelo complemento de encaminhamento de aplicações. Substitui-o pelo nome da classe do controlador de entrada se usares uma implementação diferente.

Controlador de ingresso

Um controlador de entrada alojado em cluster funciona como uma carga de trabalho num nó AKS e observa pedidos recebidos. O tráfego recebido é então distribuído com base nas regras definidas no recurso de entrada associado a esse controlador. Embora o controlador de entrada mais comum seja baseado em NGINX, o AKS não restringe você a um controlador específico. Pode utilizar Application Gateway para Containers, Contour, HAProxy, Traefik e outros.

Deve programar controladores de ingresso alojados no cluster num nó Linux. Indique que o recurso deve ser executado num nó baseado em Linux, utilizando um seletor de nós no seu manifesto YAML ou na implementação do Helm chart. Para obter mais informações, consulte Usar seletores de nó para controlar onde os pods são agendados no AKS.

Entrada com o complemento de encaminhamento de aplicações

O suplemento de encaminhamento de aplicações fornece implementações de ingresso geridas para o AKS. Para implementações novas e duradouras, utilize a implementação da API Gateway para encaminhamento de aplicações, se esta cumprir os seus requisitos. A Gateway API é o padrão a longo prazo para o tráfego de entrada no Kubernetes e para a gestão de tráfego da Camada 7.

A implementação gerida do NGINX oferece as seguintes funcionalidades:

• Fácil configuração de controladores NGINX Ingress gerenciados baseados no controlador Kubernetes NGINX Ingress.
• Integração com DNS do Azure para gestão de zonas públicas e privadas.
• Terminação SSL com certificados armazenados no Azure Key Vault.

Para mais informações, veja Configurar entrada com a API de Gateway de roteamento de aplicações e Entrada NGINX gerida com o complemento de encaminhamento de aplicações.

Proteja o tráfego com um firewall de aplicativo da Web (WAF)

Orientações sobre boas práticas

Para analisar o tráfego recebido em busca de potenciais ataques, utilize um firewall de aplicações web (WAF) como Barracuda WAF for Azure ou Firewall de Aplicações Web do Azure on Application Gateway for Containers. O Gateway de Aplicação para Contentores encaminha tráfego HTTP, HTTPS, gRPC, WebSocket e de inferência de IA e suporta a terminação de TLS.

Um controlador de entrada alojado em cluster funciona como uma carga de trabalho Kubernetes no seu cluster AKS e distribui o tráfego para serviços e aplicações. Consome alguns dos recursos do nó, como CPU, memória e largura de banda de rede. Em ambientes maiores, poderá querer considerar o seguinte:

• Descarregue parte desse roteamento de tráfego ou terminação TLS para um recurso de rede fora do cluster AKS.
• Analise o tráfego de entrada em busca de possíveis ataques.

O diagrama ilustra o tráfego externo a passar pelo Gateway de Aplicação do Azure for Containers. Quando a proteção WAF está configurada, as regras WAF filtram os pedidos antes de o Application Gateway for Containers encaminhar o tráfego permitido para os serviços no cluster AKS.

Para essa camada extra de segurança, um firewall de aplicações web (WAF) filtra o tráfego recebido. As regras geridas e personalizadas protegem contra ataques como criação de scripts entre sites e injeção SQL. O Application Gateway for Containers é um serviço de balanceamento de carga e gestão de tráfego da Camada 7 que suporta o Azure WAF.

A proteção WAF não fica ativada apenas com a implementação do Application Gateway for Containers. Deve criar uma política WAF e completar ambas as seguintes configurações antes de o WAF inspecionar o tráfego:

• Crie um recurso filho do Azure SecurityPolicy que faça referência à política WAF.
• Aplique um recurso personalizado Kubernetes WebApplicationFirewallPolicy que faça referência à mesma política WAF e que tenha como alvo o Gateway recurso ou HTTPRoute a proteger.

Depois de completares ambas as configurações, verifica o estado personalizado dos recursos e os registos WAF antes de confiares na política para proteção. Para mais informações, consulte Firewall de Aplicações Web do Azure on Application Gateway for Containers.

Como outras soluções de terceiros também executam essas funções, você pode continuar a usar os investimentos existentes ou a experiência em seu produto preferido.

O balanceador de carga ou os recursos de entrada são executados continuamente em seu cluster AKS e refinam a distribuição de tráfego. Gateway de Aplicação do Azure para Containers pode ser gerido centralmente como controlador de entrada com uma definição de recurso. Para começar, crie um Application Gateway para Containers e depois configure a proteção WAF separadamente.

Controle o fluxo de tráfego com políticas de rede

Orientações sobre boas práticas

Use Políticas de Rede para permitir ou negar tráfego para os pods. Por padrão, todo o tráfego é permitido entre pods dentro de um cluster. Para maior segurança, defina regras que limitem a comunicação do pod.

A política de rede é um recurso do Kubernetes disponível no AKS que permite controlar o fluxo de tráfego entre pods. Você permite ou nega tráfego para o pod com base em configurações como rótulos atribuídos, namespace ou porta de tráfego. As políticas de rede são uma maneira nativa da nuvem de controlar o fluxo de tráfego para pods. Como os pods são criados dinamicamente em um cluster AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.

Para usar políticas de rede no AKS, selecione um motor de políticas de rede que suporte os sistemas operativos dos seus nós e o plano de dados da rede. Pode ativar um motor de políticas durante a criação do cluster ou num cluster já suportado.

Para conjuntos de nós Linux, utilize o Azure CNI com tecnologia Cilium e a imposição incorporada de políticas de rede do Cilium. O Cilium não é suportado para pools de nós do Windows. Para cargas de trabalho do Windows, use o Calico.

Você cria uma política de rede como um recurso do Kubernetes usando um manifesto YAML. As políticas são aplicadas a pods definidos, com regras de entrada ou saída que definem o fluxo de tráfego.

O exemplo a seguir aplica uma política de rede a pods com o rótulo app: backend aplicado a eles. A regra de ingresso só permite tráfego de pods com a etiqueta app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Para começar com políticas, veja Tráfego seguro entre pods usando políticas de rede em Azure Kubernetes Service (AKS).

Otimize a resolução DNS com LocalDNS

Orientações sobre boas práticas

Use o LocalDNS para melhorar o desempenho e a fiabilidade do DNS e reduzir a carga nos pods centralizados do CoreDNS. O LocalDNS está pré-configurado no AKS Automatic. No AKS Standard, ative e configure o LocalDNS por pool de nós.

O LocalDNS instala um proxy DNS como um systemd serviço em cada nó para processar consultas DNS localmente. Por predefinição, os pods enviam todas as consultas DNS para pods CoreDNS centralizados. Em larga escala, centralizar estas consultas pode criar um gargalo, enquanto a resolução local reduz os saltos e a latência da rede.

O LocalDNS também elimina conntrack entradas de tabela para tráfego DNS, prevenindo conntrack o esgotamento das tabelas e condições de corrida que podem causar falhas de ligações. As ligações da cache local para o CoreDNS são atualizadas para TCP, permitindo o reequilíbrio da ligação e uma limpeza mais rápida das entradas de rastreio.

Para cargas de trabalho que requerem elevada disponibilidade de DNS, o LocalDNS suporta fornecer respostas em cache obsoletas durante um período configurável quando o DNS a montante não está disponível. Esta capacidade de melhor esforço pode ajudar a manter a conectividade dos pods e a fiabilidade do serviço durante falhas temporárias de DNS, mas não garante que um registo obsoleto esteja disponível.

No AKS Standard, ativar o LocalDNS num pool de nós existente recria a imagem dos nós. Planeie o lançamento para ter em conta esta perturbação.

Para mais informações sobre a arquitetura e capacidades do LocalDNS, consulte resolução DNS no AKS. Para instruções de configuração, consulte Configurar LocalDNS.

Ligue-se de forma segura aos nós

Orientações sobre boas práticas

Não exponha o acesso remoto aos nós da AKS. Para a resolução rotineira de problemas de nós Linux, use kubectl debug através da API do Kubernetes. Quando precisar de acesso SSH, ligue-se através de redes privadas ou Azure Bastion.

Pode completar a maioria das operações no AKS usando ferramentas de gestão do Azure ou o servidor API Kubernetes. Os nós AKS só estão disponíveis em uma rede privada e não estão conectados à internet pública. Para os nós Linux, use kubectl debug para iniciar um contentor de depuração privilegiado através da API do Kubernetes. Esta abordagem não requer uma ligação SSH direta ao nó.

Se o acesso à API do Kubernetes não for apropriado ou se precisar de SSH, utilize o endereço IP privado do nó a partir de uma rede com acesso. O Azure Bastion pode fornecer conectividade privada sem expor um endereço IP público no nó. Para nós do Windows, utilize um contentor de processo do anfitrião ou ligue-se através de um nó proxy Linux. Azure Bastion é uma alternativa se o nó proxy não estiver disponível. Para mais informações, consulte Ligar aos nós do cluster AKS para manutenção ou resolução de problemas.

O diagrama ilustra uma rede virtual de gestão que contém um host bastião que encaminha as ligações através de uma ligação com emparelhamento seguro para a rede virtual do cluster AKS.

Se utilizar um anfitrião bastião ou uma jump box, coloque-o numa rede virtual de gestão separada, emparelhada de forma segura. Assegure a rede de gestão utilizando Azure ExpressRoute ou um gateway VPN para se ligar a uma rede local e controlar o acesso com grupos de segurança de rede.

Próximos passos

Este artigo concentrou-se na conectividade e segurança da rede. Para mais informações sobre os conceitos básicos de rede no Kubernetes, consulte Conceitos de rede para aplicações no Azure Kubernetes Service (AKS)