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

Ao criar e gerenciar clusters em AKS (Serviço de Kubernetes do Azure), você fornece conectividade de rede para seus nós e aplicativos. Esses recursos de rede incluem os intervalos de endereços IP, balanceadores de carga e controladores de entrada.

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

Escolha o modelo de rede apropriado

Orientação de melhor prática

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

Redes virtuais fornecem a conectividade básica para que os clientes acessem seus aplicativos e nós do AKS. Há duas maneiras diferentes para implantar clusters AKS em redes virtuais:

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

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

visão geral da rede CNI Azure

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

O diagrama a seguir mostra dois nós do AKS, cada um conectado por meio de uma ponte de rede a uma rede virtual Azure compartilhada.

Azure rede CNI permite a separação de controle e gerenciamento de recursos. De uma perspectiva de segurança, você geralmente deseja diferentes equipes para gerenciar e proteger esses recursos. As características de conectividade dependem do modelo de rede. Os pods de sobreposição iniciam conexões com a rede virtual e recursos locais por meio do endereço IP do nó. Os pods de rede simples podem se comunicar diretamente com recursos conectados por meio de seus endereços IP privados.

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

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

Por padrão, o AKS usa uma identidade gerenciada para sua identidade de cluster. Porém, em vez disso, você pode usar uma entidade de serviço.

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

Planeje 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 para os nós e use um CIDR privado separado para os pods. Cada nó recebe um /24 espaço de endereço do CIDR do pod.
• Com uma rede plana, dimensione as sub-redes da rede virtual para abranger tanto os nós quanto os pods. A Azure CNI Pod Subnet utiliza sub-redes separadas para nó e pod, enquanto a Azure CNI Node Subnet herdada utiliza uma única sub-rede para ambos.
• Evite usar intervalos de endereços IP que se sobrepõem a recursos de rede existentes.
  • É necessário permitir a conectividade com redes emparelhadas ou locais no Azure.
• Para lidar com eventos de expansão ou atualizações de cluster, você precisa de endereços IP extras disponíveis na sub-rede atribuída.
  • Esse espaço de endereço extra é especialmente importante se você usar contêineres do Windows Server, pois esses grupos de nós precisam ser atualizados 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 espaço de endereço IP necessário, consulte o planejamento de endereço IP para clusters do AKS.

Ao criar um cluster com Azure rede CNI, você especifica outros intervalos de endereços para o cluster, como o IP do serviço DNS e o intervalo de endereços de serviço. Em geral, verifique se esses intervalos de endereços não se sobrepõem uns aos outros ou a qualquer rede associada ao cluster, incluindo redes virtuais, sub-redes, redes locais e redes emparelhadas.

Para obter detalhes sobre modelos de rede, limites e dimensionamento de endereços, consulte Azure visão geral da rede CNI.

Distribuir o tráfego de entrada

Orientação de melhor prática

Para distribuir o tráfego HTTP ou HTTPS para seus aplicativos, use os recursos de entrada e controladores. Em comparação com um balanceador de carga Azure, os controladores de entrada fornecem recursos extras e podem ser gerenciados como recursos nativos do Kubernetes.

Embora um balanceador de carga Azure possa distribuir o tráfego do cliente para aplicativos em seu cluster do AKS, ele é limitado no entendimento 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 da Web que usam HTTP ou HTTPS deve usar recursos e controladores de entrada do Kubernetes, que funcionam na camada 7. A entrada pode distribuir o tráfego com base na URL do aplicativo e manusear o término TLS/SSL. A entrada também reduz o número de endereços IP para expor e mapear.

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 recebendo tráfego externo e um controlador de entrada distribuindo esse tráfego para vários serviços no cluster do AKS.

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

Recurso de entrada

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

O manifesto YAML de exemplo a seguir usa a classe NGINX Ingress gerenciada do complemento de roteamento de aplicativos. Ele distribui o tráfego para 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: 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 em um controlador de entrada no cluster. O valor webapprouting.kubernetes.azure.com seleciona o controlador de entrada NGINX gerenciado fornecido pelo complemento de roteamento de aplicativos. Substitua-o pelo nome da classe do controlador de entrada se você usar uma implementação diferente.

Controlador de entrada

Um controlador de ingresso hospedado no cluster é executado como carga de trabalho em um nó do AKS e monitora solicitações recebidas. O tráfego de entrada é 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. Você pode usar Application Gateway for Containers, Contour, HAProxy, Traefik e outros.

Você deve executar os controladores de ingresso hospedados no cluster em um nó Linux. Indique que o recurso deve ser executado em um nó baseado em Linux usando um seletor de nó no manifesto YAML ou na implantação do gráfico do Helm. Para obter mais informações, consulte Usar seletores de nó para controlar em que local os pods são agendados no AKS.

Ingress com o complemento de roteamento de aplicativo

O complemento de roteamento de aplicativos fornece implementações de entrada gerenciadas para o AKS. Para implantações novas e de longa duração, use a implementação da Gateway API para roteamento de aplicativos quando ela atender aos seus requisitos. A API de Gateway é o padrão de longo prazo para entrada do Kubernetes e gerenciamento de tráfego de camada 7.

A implementação gerenciada do NGINX fornece os seguintes recursos:

• Configuração fácil de controladores de entrada NGINX gerenciados com base no controlador de entrada NGINX do Kubernetes.
• Integração com DNS do Azure para gerenciamento de zona pública e privada.
• Terminação SSL com certificados armazenados em Azure Key Vault.

Para obter mais informações, consulte Configurar o ingress com a API Gateway de roteamento de aplicativos e NGINX ingress gerenciado com o suplemento de roteamento de aplicativos.

Tráfego seguro com um firewall do aplicativo Web (WAF)

Orientação de melhor prática

Para inspecionar o tráfego de entrada em busca de possíveis ataques, use um firewall de aplicativo web (WAF), como o Barracuda WAF for Azure ou o Firewall de Aplicativo Web do Azure on Application Gateway for Containers. O Gateway de Aplicação para Contêineres roteia tráfego HTTP, HTTPS, gRPC, WebSocket e de inferência de IA, e suporta terminação de TLS.

Um controlador de entrada hospedado por cluster é executado como uma carga de trabalho do Kubernetes no cluster do AKS e distribui o tráfego para serviços e aplicativos. Ele consome alguns dos recursos do nó, como CPU, memória e largura de banda de rede. Em ambientes maiores, talvez você queira considerar o seguinte:

• Descarregar alguns desses roteamentos de tráfego ou a terminação TLS a um recurso de rede fora do cluster do AKS.
• Verificar o tráfego de entrada para possíveis ataques.

O diagrama ilustra o tráfego externo que passa por Gateway de Aplicativo do Azure para contêineres. Quando a proteção do WAF é configurada, as regras do WAF filtram solicitações antes que o Gateway de Aplicativo para Contêineres encaminhe o tráfego permitido para serviços no cluster do AKS.

Para essa camada extra de segurança, um WAF (firewall de aplicativo Web) filtra o tráfego de entrada. As regras gerenciadas e personalizadas protegem contra ataques como script entre sites e injeção de SQL. O Application Gateway para Contêineres é um serviço de balanceamento de carga e gerenciamento de tráfego da camada 7 que oferece suporte ao Azure WAF.

A proteção do WAF não é habilitada apenas com a implantação do Application Gateway for Containers. Você deve criar uma política de WAF e concluir ambas as seguintes configurações antes que o WAF inspecione o tráfego:

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

Depois de concluir as duas configurações, verifique o status do recurso personalizado e os logs de WAF antes de depender da política de proteção. Para obter mais informações, consulte Firewall de Aplicativo Web do Azure no Gateway de Aplicativo para Contêineres.

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

Recursos de entrada ou do balanceador de carga continuam sendo executados no cluster do AKS e refinam a distribuição de tráfego. Gateway de Aplicativo do Azure para Contêineres pode ser gerenciado centralmente como um controlador de entrada com uma definição de recurso. Para começar, crie um Gateway de Aplicativo para Contêineres e configure a proteção do WAF separadamente.

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

Orientação de melhor prática

Use as políticas de rede para permitir ou negar o tráfego para pods. Por padrão, todo o tráfego é permitido entre pods dentro de um cluster. Para maior segurança, defina regras que limitam a comunicação entre pods.

A política de rede é um recurso de Kubernetes disponível no AKS que permite controlar o fluxo de tráfego entre os pods. Você permite ou nega o tráfego para o pod de acordo com as configurações, como rótulos atribuídos, namespace ou porta de tráfego. 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 do AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.

Para usar políticas de rede no AKS, selecione um mecanismo de política de rede que dê suporte aos sistemas operacionais dos nós e ao plano de dados de rede. Você pode habilitar um mecanismo de política durante a criação do cluster ou em um cluster com suporte existente.

Para conjuntos de nós Linux, use o Azure CNI com tecnologia Cilium e a aplicação interna das políticas de rede do Cilium. O Cilium não tem suporte para pools de nós do Windows. Para cargas de trabalho Windows, use 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 aos pods com o rótulo app: back-end aplicado. A regra de entrada permite apenas o tráfego de pods com o rótulo 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 Proteja o tráfego entre pods usando políticas de rede no AKS (Serviço de Kubernetes do Azure).

Otimizar a resolução de DNS com LocalDNS

Orientação de melhor prática

Use o LocalDNS para melhorar o desempenho e a confiabilidade do DNS e reduzir a carga em pods CoreDNS centralizados. LocalDNS é pré-configurado no AKS Automatic. No AKS Standard, habilite e configure o LocalDNS por pool de nós.

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

O LocalDNS também elimina as entradas conntrack de tabela para o tráfego DNS, evitando o esgotamento da conntrack tabela e as situações de corrida que podem resultar em conexões interrompidas. As conexões do cache local para o CoreDNS são atualizadas para TCP, permitindo o reequilíbrio de conexão e a limpeza mais rápida das entradas de acompanhamento.

Para cargas de trabalho que exigem alta disponibilidade de DNS, o LocalDNS dá suporte ao serviço de respostas obsoletas armazenadas em cache por uma duração configurável quando o DNS upstream não está disponível. Essa funcionalidade de melhor esforço pode ajudar a manter a conectividade do pod e a confiabilidade do serviço durante interrupções de DNS transitórias, mas não garante que um registro obsoleto esteja disponível.

No AKS Standard, habilitar o LocalDNS em um pool de nós existente recria a imagem dos nós. Planeje a distribuição para considerar essa interrupção.

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

Conecte-se com segurança a nodos

Orientação de melhor prática

Não exponha a conectividade remota aos seus nós do AKS. Para a solução de problemas rotineiros em nós Linux, use kubectl debug pela API do Kubernetes. Quando precisar de acesso SSH, conecte-se por meio de rede privada ou Azure Bastion.

Você pode concluir a maioria das operações no AKS usando Azure ferramentas de gerenciamento ou o servidor de API do Kubernetes. Os nós do AKS não estão disponíveis em uma rede privada e não estão conectados à internet pública. Para nós Linux, use kubectl debug para iniciar um contêiner de depuração privilegiado por meio da API do Kubernetes. Essa abordagem não requer conectividade SSH direta com o nó.

Se o acesso à API do Kubernetes não for adequado ou você precisar de SSH, use o endereço IP privado do nó de uma rede conectada. Azure Bastion pode fornecer conectividade privada sem expor um endereço IP público no nó. Para nós do Windows, use um contêiner de processo de host ou conecte-se por meio de um nó de proxy do Linux. Azure Bastion será uma alternativa se o nó proxy não estiver disponível. Para obter mais informações, consulte Conectar-se aos nós de cluster do AKS para manutenção ou solução de problemas.

O diagrama ilustra uma rede virtual de gerenciamento que contém um host bastion que roteia conexões por meio de um link emparelhado com segurança para a rede virtual do cluster do AKS.

Se você usar um bastion host ou uma jump box, coloque-o em uma rede virtual de gerenciamento separada e emparelhada de forma segura. Proteja a rede de gerenciamento usando Azure ExpressRoute ou um gateway de VPN para se conectar a uma rede local e controlar o acesso com grupos de segurança de rede.

Próximas etapas

Este artigo se concentra na conectividade de rede e segurança. Para obter mais informações sobre as noções básicas de rede no Kubernetes, consulte Conceitos de rede para aplicativos no AKS (Serviço de Kubernetes do Azure)