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 a rede CNI do Azure no AKS para integração com redes virtuais existentes ou redes locais. Este modelo de rede permite uma maior separação de recursos e controlos num ambiente empresarial.

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:

• Azure CNI networking: Implementa numa rede virtual e utiliza o plugin Kubernetes Azure CNI. Os pods recebem IPs individuais que podem ser roteados para outros serviços de rede ou recursos locais.

O Azure CNI é uma opção válida para implementações em produção.

Rede CNI

O Azure CNI é um protocolo neutro em relação ao fornecedor que permite ao tempo de execução do contentor fazer pedidos a um fornecedor de rede. Atribui endereços IP a pods e nós, e fornece funcionalidades de gestão de endereços IP (IPAM) à medida que se liga a redes virtuais Azure existentes. Cada nó e recurso pod recebe um endereço IP na rede virtual do Azure. Não há necessidade de roteamento extra para se comunicar com outros recursos ou serviços.

Notavelmente, a rede CNI do Azure para produção permite a separação de 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. Com a rede Azure CNI, liga-se diretamente aos recursos Azure existentes, recursos locais ou outros serviços através de endereços IP atribuídos a cada pod.

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:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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.

Como cada nó e pod recebe o seu próprio endereço IP, planeie os intervalos de endereços para as sub-redes AKS. Tenha em mente os seguintes critérios:

• A sub-rede deve ser grande o suficiente para fornecer endereços IP para cada nó, pod e recurso de rede que implantar.
  • Com a rede Azure CNI, cada nó em execução tem limites predefinidos para o número de pods.
• 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 endereço IP necessário, veja Configure Azure CNI networking in AKS.

Ao criar um cluster com rede Azure CNI, especifica outros intervalos de endereços para o cluster, como o endereço da ponte Docker, o IP do serviço DNS e o intervalo de endereços do serviço. Em geral, certifique-se de que esses intervalos de endereços não se sobreponham uns aos outros ou a quaisquer redes associadas ao cluster, incluindo redes virtuais, sub-redes, redes locais e emparelhadas.

Para detalhes específicos sobre limites e dimensionamento destes intervalos de endereços, veja Configure Azure rede CNI em AKS.

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.

Existem dois componentes para a entrada:

1. Um recurso de ingresso
2. 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 exemplo de manifesto YAML a seguir distribui o tráfego de myapp.com para um dos dois serviços, blogservice ou storeservice, e direciona o cliente para um serviço ou outro com base na URL que ele acessa.

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

Controlador de ingresso

Um controlador de entrada é um daemon que é executado em um nó AKS e observa as solicitações recebidas. O tráfego é então distribuído com base nas regras definidas no recurso de entrada. Embora o controlador de entrada mais comum seja baseado em NGINX, o AKS não restringe você a um controlador específico. Pode usar Application Gateway para Containers, Contour, HAProxy, Traefik, etc.

Os controladores Ingress devem ser agendados num nó Linux. Indique que o recurso deve ser executado num nó baseado em Linux usando um seletor de nós no seu manifesto YAML ou na implementação de gráfico Helm. Para obter mais informações, consulte Usar seletores de nó para controlar onde os pods são agendados no AKS.

Ingressar com o complemento de roteamento de aplicativos

O complemento de roteamento de aplicativos é a maneira recomendada de configurar um controlador Ingress no AKS. O addon de encaminhamento de aplicações é um controlador de entrada totalmente gerido para o Azure Kubernetes Service (AKS) que fornece 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 obter mais informações sobre o complemento de roteamento de aplicativo, consulte Ingresso NGINX gerenciado com o complemento de roteamento de aplicativo.

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 o WAF Barracuda para Azure ou Gateway de Aplicação do Azure para Containers. Esses recursos de rede mais avançados também podem rotear o tráfego além de apenas conexões HTTP e HTTPS ou terminação TLS básica.

Normalmente, um controlador de entrada é um recurso do Kubernetes em seu cluster AKS que distribui tráfego para serviços e aplicativos. O controlador é executado como um daemon em um nó AKS e consome alguns dos recursos do nó, como CPU, memória e largura de banda de rede. Em ambientes maiores, convém 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.

Para essa camada extra de segurança, um firewall de aplicativo Web (WAF) filtra o tráfego de entrada. Com um conjunto de regras, o Open Web Application Security Project (OWASP) vigia ataques como cross-site scripting ou envenenamento por cookies. Gateway de Aplicação do Azure para Containers é um WAF que se integra com clusters AKS, bloqueando estas funcionalidades de segurança antes que o tráfego chegue ao seu cluster AKS e aplicações.

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 Gateway de Aplicações para Containers.

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, o recurso pode ser ativado durante a criação do cluster ou em um cluster AKS existente. Se você estiver planejando usar políticas de rede, verifique se o recurso está habilitado no cluster AKS.

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

Ative o LocalDNS nos seus pools de nós AKS para melhorar o desempenho do DNS, a fiabilidade e reduzir a carga nos pods centralizados CoreDNS.

A resolução DNS é fundamental para a comunicação entre serviços no Kubernetes. Por padrão, todas as consultas DNS dos pods são enviadas para os pods CoreDNS centralizados, que podem tornar-se um gargalo quando em grande escala. AKS oferece LocalDNS, que implementa um proxy DNS como systemd serviço em cada nó. Este proxy gere as consultas DNS localmente, reduzindo os saltos de rede e a latência de resolução.

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 ajuda a manter a conectividade dos pods e a fiabilidade do serviço durante interrupções temporárias do DNS.

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.

Conecte-se com segurança aos nós por meio de um host bastion

Orientações sobre boas práticas

Não exponha o acesso remoto aos nós da AKS. Crie um host bastião, ou servidor intermediário, numa rede virtual de gestão. Use o host bastion para rotear com segurança o tráfego para seu cluster AKS para tarefas de gerenciamento remoto.

Pode completar a maioria das operações no AKS usando as ferramentas de gestão do Azure ou através do 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 se conectar a nós e fornecer manutenção e suporte, roteie as suas ligações por meio de um bastion host ou jump box. Verifique se este host está numa rede virtual de gestão separada, interligada de forma segura à rede virtual do cluster AKS.

Você também deve proteger a rede de gerenciamento para o host bastião. Utilize um Azure ExpressRoute ou um gateway VPN para se conectar a uma rede no local e controlar o acesso usando 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)