Práticas recomendadas para conectividade de rede e segurança no Serviço Kubernetes do Azure (AKS)

2025-06-05

Importante

Em 31 de março de 2028, a rede kubenet para o Serviço Kubernetes do Azure (AKS) será desativada.

Para evitar interrupções de serviço, precisarásatualizar para a interface CNI de sobreposição (Container Networking Interface) do Azureantes dessa data, quando os workloads executados no kubenet para o AKS não forem mais suportados.

Ao criar e gerenciar clusters no Serviço Kubernetes do Azure (AKS), você fornece conectividade de rede para seus nós e aplicativos. 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:

Explique o modo de rede CNI (Container Networking Interface) do Azure no AKS.
Planeje o endereçamento IP e a conectividade necessários.
Distribua o tráfego usando balanceadores de carga, controladores de entrada ou um firewall de aplicativo Web (WAF).
Conecte-se com segurança aos nós do cluster.

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:

Rede CNI do Azure: implanta em uma rede virtual e usa o plug-in Kubernetes do 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 implantações de produção.

Rede CNI

O Azure CNI é um protocolo neutro do fornecedor que permite que o tempo de execução do contêiner faça solicitações a um provedor de rede. Ele atribui endereços IP a pods e nós e fornece recursos de gerenciamento de endereços IP (IPAM) à medida que você se conecta a redes virtuais existentes do Azure. Cada recurso, tanto de nó quanto de 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.

Diagrama mostrando dois nós com pontes conectando cada um a uma única VNet do Azure

Notavelmente, a rede CNI do Azure para produção permite a separação do controle e do gerenciamento de recursos. Do ponto de vista da segurança, muitas vezes você deseja que equipes diferentes gerenciem e protejam esses recursos. Com a rede CNI do Azure, você se conecta a recursos existentes do Azure, recursos locais ou outros serviços diretamente por meio de endereços IP atribuídos a cada pod.

Quando você usa a rede CNI do Azure, o recurso de rede virtual está em um grupo de recursos separado para o 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 obter 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.
- Na rede CNI do Azure, cada nó ativo tem limites padrão 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 a conectividade com redes locais ou emparelhadas no Azure.
Para lidar com eventos de expansão ou atualizações de cluster, você precisa de endereços IP adicionais disponíveis na sub-rede atribuída.
- Esse espaço de endereçamento extra é especialmente importante se você usar contêineres do Windows Server, pois esses pools de nós exigem uma atualização para aplicar os patches de segurança mais recentes. Para obter mais informações sobre nós do Windows Server, consulte Atualizar um pool de nós no AKS.

Para calcular o endereço IP necessário, consulte Configurar a rede CNI do Azure no AKS.

Ao criar um cluster com rede CNI do Azure, você especifica outros intervalos de endereços para o cluster, como o endereço da ponte do 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 obter detalhes específicos sobre limites e dimensionamento para esses intervalos de endereços, consulte Configurar a rede CNI do Azure no 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. Em comparação com um balanceador de carga do Azure, os controladores de entrada fornecem recursos extras e podem ser gerenciados como recursos nativos do Kubernetes.

Embora um balanceador de carga do Azure possa distribuir o tráfego do cliente para aplicativos em seu cluster AKS, ele é 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.

Diagrama mostrando o fluxo de tráfego de entrada em um cluster AKS

Existem dois componentes para a entrada:

Um recurso de ingresso
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. Você pode usar 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 complemento de roteamento de aplicativo é um controlador de entrada totalmente gerenciado para o Serviço Kubernetes do Azure (AKS) que fornece os seguintes recursos:

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

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 verificar o tráfego de entrada em busca de possíveis ataques, use um firewall de aplicativo Web (WAF), como o Barracuda WAF para Azure ou o Azure Application Gateway. 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.

Um firewall de aplicativo Web (WAF), como o Azure App Gateway, pode proteger e distribuir tráfego para seu cluster AKS

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) observa ataques como scripts entre sites ou envenenamento de cookies. O Azure Application Gateway (atualmente em pré-visualização no AKS) é um WAF que se integra com clusters AKS, bloqueando esses recursos de segurança antes que o tráfego chegue ao cluster e aos aplicativos AKS.

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. O App Gateway pode ser gerenciado centralmente como um controlador de entrada com uma definição de recurso. Para começar, crie um controlador de entrada do Application Gateway.

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.

Observação

As políticas de rede podem ser utilizadas para nodes e pods baseados em Linux ou Windows no 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 a usar políticas, consulte Proteger o tráfego entre pods usando políticas de rede no Serviço Kubernetes do Azure (AKS).

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

Orientações sobre boas práticas

Não exponha a conectividade remota aos seus nós AKS. Crie um host bastião, ou caixa de salto, em uma rede virtual de gerenciamento. Use o host bastion para rotear com segurança o tráfego para seu cluster AKS para tarefas de gerenciamento remoto.

Você pode concluir a maioria das operações no AKS usando as ferramentas de gerenciamento do Azure ou por meio do servidor de API do 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.

Conecte-se aos nodos AKS usando um servidor bastião ou 'jump box'

Você também deve proteger a rede de gerenciamento para o host bastião. Use uma Rota Expressa do Azure ou gateway VPN para se conectar a uma rede 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 obter mais informações sobre noções básicas de rede no Kubernetes, consulte Conceitos de rede para aplicativos no Serviço Kubernetes do Azure (AKS)