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

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, vai aprender a:

• Compare os modos de rede kubenet e CNI (Azure Container Networking Interface) 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 nós AKS e clientes acessarem 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.
• Rede Kubenet: o Azure gerencia os recursos de rede virtual à medida que o cluster é implantado e usa o plug-in Kubernetes kubenet .

Azure CNI e kubenet são opções válidas 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 de nó e 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 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 dentro 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 uma entidade de serviço.

• Para obter mais informações sobre a delegação da entidade de serviço 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 seu próprio endereço IP, planeje 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 implantado.
  • Com a rede kubenet e Azure CNI, cada nó em execução 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.

Rede Kubenet

Embora o kubenet não exija que você configure as redes virtuais antes de implantar o cluster, há desvantagens em esperar, como:

• Como nós e pods são colocados em sub-redes IP diferentes, o UDR (User Defined Routing) e o encaminhamento IP roteiam o tráfego entre pods e nós. Esse roteamento extra pode reduzir o desempenho da rede.
• As conexões com redes locais existentes ou o emparelhamento com outras redes virtuais do Azure podem ser complexos.

Como você não cria a rede virtual e as sub-redes separadamente do cluster AKS, o Kubenet é ideal para os seguintes cenários:

• Pequenas cargas de trabalho de desenvolvimento ou teste.
• Sites simples com baixo tráfego.
• Levantamento e transferência de cargas de trabalho para contêineres.

Para implantações de produção, kubenet e Azure CNI são opções válidas. Ambientes que exigem separação de controle e gerenciamento, o Azure CNI pode ser a opção preferida. Além disso, o kubenet é adequado apenas para ambientes Linux onde a conservação do intervalo de endereços IP é uma prioridade.

Você também pode configurar seus próprios intervalos de endereços IP e redes virtuais usando kubenet. Como a rede CNI do Azure, esses intervalos de endereços não devem se sobrepor uns aos outros ou a quaisquer redes associadas ao cluster (redes virtuais, sub-redes, redes locais e emparelhadas).

Para obter detalhes específicos sobre limites e dimensionamento para esses intervalos de endereços, consulte Usar rede kubenet com seus próprios intervalos de endereços IP 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 ingresso também reduz o número de endereços IP que você expõe e mapeia.

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 ingresso

O recurso de ingresso é 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 entradas

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 de entrada devem ser agendados em um nó Linux. Indique que o recurso deve ser executado em um nó baseado em Linux usando um seletor de nó em seu manifesto YAML ou implantaçã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.

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 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 a política de rede, habilite o recurso ao criar um novo cluster AKS. Não é possível ativar a política de rede em um cluster AKS existente. Planeje com antecedência para habilitar a diretiva de rede nos clusters necessários.

Nota

A política de rede só deve ser usada para nós e pods baseados em Linux 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 aplicativo: rótulo de back-end aplicado a eles. A regra de ingresso só permite tráfego de pods com o aplicativo: frontend label.

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 suas conexões por meio de um host bastion ou jump box. Verifique se esse host vive em uma rede virtual de gerenciamento separada e emparelhada com segurança para a rede virtual do cluster AKS.

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)