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

À medida que cria e gere clusters no Azure Kubernetes Service (AKS), fornece conectividade de rede para os nós e aplicações. Estes recursos de rede incluem intervalos de endereços IP, balanceadores de carga e controladores de entrada.

Este artigo de melhores práticas centra-se na conectividade de rede e na segurança dos operadores de cluster. Neste artigo, vai aprender a:

• Compare os modos de rede kubenet e Azure Container Networking Interface (CNI) no AKS.
• Planeie a conectividade e o endereçamento IP necessários.
• Distribua o tráfego com balanceadores de carga, controladores de entrada ou uma firewall de aplicações Web (WAF).
• Ligue-se de forma segura aos nós de cluster.

Escolher o modelo de rede adequado

Documentação de orientação sobre as melhores práticas

Utilize a rede CNI do Azure no AKS para integração com redes virtuais existentes ou redes no local. 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 que os nós do AKS e os clientes acedam às suas aplicações. Existem duas formas diferentes de implementar clusters do AKS em redes virtuais:

• Rede CNI do Azure: implementa numa rede virtual e utiliza o plug-in kubernetes do Azure CNI . Os pods recebem IPs individuais que podem ser encaminhados para outros serviços de rede ou recursos no local.
• Redes kubenet: o Azure gere os recursos de rede virtual à medida que o cluster é implementado e utiliza o plug-in kubenet Kubernetes.

O Azure CNI e o kubenet são opções válidas para implementações de produção.

Rede CNI

O Azure CNI é um protocolo neutro do fornecedor que permite que o runtime do contentor faça 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 do Azure existentes. Cada recurso de nó e pod recebe um endereço IP na rede virtual do Azure. Não é necessário encaminhamento adicional para comunicar com outros recursos ou serviços.

Nomeadamente, as redes CNI do Azure para produção permitem separar o controlo e a gestão de recursos. Do ponto de vista da segurança, muitas vezes quer que equipas diferentes giram e protejam esses recursos. Com a rede CNI do Azure, liga-se a recursos existentes do Azure, recursos no local ou a outros serviços diretamente através de endereços IP atribuídos a cada pod.

Quando utiliza a rede CNI do Azure, o recurso de rede virtual está num grupo de recursos separado do cluster do AKS. Delegar permissões para a identidade do cluster do AKS para aceder e gerir estes recursos. A identidade do cluster utilizada pelo cluster do AKS tem de ter, pelo menos, permissões de Contribuidor de Rede na sub-rede na rede virtual.

Se quiser definir uma função personalizada em vez de utilizar a função contribuidor de rede incorporada, são necessárias as seguintes permissões:

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

Por predefinição, o AKS utiliza uma identidade gerida para a respetiva identidade de cluster. No entanto, pode utilizar um principal de serviço como alternativa.

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

À medida que cada nó e pod recebe o seu próprio endereço IP, planeie os intervalos de endereços das sub-redes do AKS. Tenha em atenção os seguintes critérios:

• A sub-rede tem de ser suficientemente grande para fornecer endereços IP para cada nó, pod e recurso de rede que implementar.
  • Com as redes kubenet e CNI do Azure, cada nó em execução tem limites predefinidos para o número de pods.
• Evite utilizar intervalos de endereços IP que se sobrepõem aos recursos de rede existentes.
  • É necessário permitir a conectividade a redes no local ou em modo de peering no Azure.
• Para lidar com eventos de aumento horizontal ou atualizações de clusters, precisa de endereços IP adicionais disponíveis na sub-rede atribuída.
  • Este espaço de endereços adicional é especialmente importante se utilizar contentores do Windows Server, uma vez que esses conjuntos de nós necessitam de uma atualização para aplicar os patches de segurança mais recentes. Para obter mais informações sobre nós do Windows Server, veja Atualizar um conjunto de nós no AKS.

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

Ao criar um cluster com redes CNI do Azure, especifique outros intervalos de endereços para o cluster, como o endereço da bridge do Docker, o IP do serviço DNS e o intervalo de endereços de serviço. Em geral, certifique-se de que estes intervalos de endereços não se sobrepõem entre si ou quaisquer redes associadas ao cluster, incluindo redes virtuais, sub-redes, redes no local e em modo de peering.

Para obter detalhes específicos sobre os limites e o dimensionamento destes intervalos de endereços, veja Configurar a rede CNI do Azure no AKS.

Rede do Kubenet

Embora o kubenet não exija que configure as redes virtuais antes de implementar o cluster, existem desvantagens em aguardar, tais como:

• Uma vez que os nós e pods são colocados em sub-redes IP diferentes, o Encaminhamento Definido pelo Utilizador (UDR) e o reencaminhamento IP encaminham o tráfego entre pods e nós. Este encaminhamento adicional pode reduzir o desempenho da rede.
• As ligações a redes no local existentes ou ao peering para outras redes virtuais do Azure podem ser complexas.

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

• Pequenas cargas de trabalho de desenvolvimento ou teste.
• Sites simples com pouco tráfego.
• Levantar e transferir cargas de trabalho para contentores.

Para a maioria das implementações de produção, deve planear e utilizar a rede do Azure CNI.

Também pode configurar os seus próprios intervalos de endereços IP e redes virtuais com o kubenet. Tal como a rede CNI do Azure, estes intervalos de endereços não devem sobrepor-se uns aos outros ou a quaisquer redes associadas ao cluster (redes virtuais, sub-redes, redes no local e em modo de peering).

Para obter detalhes específicos sobre limites e dimensionamento para estes intervalos de endereços, veja Utilizar redes kubenet com os seus próprios intervalos de endereços IP no AKS.

Distribuir tráfego de entrada

Documentação de orientação sobre as melhores práticas

Para distribuir o tráfego HTTP ou HTTPS para as suas aplicações, utilize os recursos e controladores de entrada. Em comparação com um balanceador de carga do Azure, os controladores de entrada fornecem funcionalidades adicionais e podem ser geridos como recursos nativos do Kubernetes.

Embora um balanceador de carga do Azure possa distribuir o tráfego do cliente pelas aplicações no cluster do 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 das aplicações Web que utilizam HTTP ou HTTPS deve utilizar os recursos e controladores de entrada do Kubernetes, que funcionam na camada 7. A entrada pode distribuir o tráfego com base no URL da aplicação e processar a terminação TLS/SSL. A entrada também reduz o número de endereços IP que expõe e mapeia.

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

Existem dois componentes para entrada:

1. Um recurso de entrada
2. Um controlador de entrada

Recurso de entrada

O recurso de entrada é um manifesto YAML de kind: Ingress. Define o anfitrião, certificados e regras para encaminhar o tráfego para serviços em execução no cluster do AKS.

O manifesto YAML de exemplo seguinte distribui o tráfego para myapp.com para um de dois serviços, blogservice ou storeservice e direciona o cliente para um serviço ou outro com base no URL a que acedem.

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 num nó do AKS e observa pedidos recebidos. Em seguida, o tráfego é distribuído com base nas regras definidas no recurso de entrada. Embora o controlador de entrada mais comum se baseie no NGINX, o AKS não o restringe a um controlador específico. Pode utilizar Contour, HAProxy, Traefik, etc.

Os controladores de entrada têm de ser agendados num nó do Linux. Indique que o recurso deve ser executado num nó baseado em Linux com um seletor de nós no seu manifesto YAML ou na implementação do gráfico Helm. Para obter mais informações, veja Utilizar seletores de nós para controlar onde os pods estão agendados no AKS.

Nota

Os nós do Windows Server não devem executar o controlador de entrada.

Existem muitos cenários de entrada, incluindo os seguintes guias de procedimentos:

• Criar um controlador de entrada básico com conectividade de rede externa
• Criar um controlador de entrada que utiliza uma rede interna privada e um endereço IP
• Criar um controlador de entrada que utiliza os seus próprios certificados TLS
• Criar um controlador de entrada que utilize Let's Encrypt para gerar automaticamente certificados TLS com um endereço IP público dinâmico ou com um endereço IP público estático

Proteger o tráfego com uma firewall de aplicações Web (WAF)

Documentação de orientação sobre as melhores práticas

Para analisar o tráfego de entrada para potenciais ataques, utilize uma firewall de aplicações Web (WAF), como Barracuda WAF para o Azure ou Gateway de Aplicação do Azure. Estes recursos de rede mais avançados também podem encaminhar o tráfego para além das ligações HTTP e HTTPS ou da terminação TLS básica.

Normalmente, um controlador de entrada é um recurso do Kubernetes no cluster do AKS que distribui o tráfego por serviços e aplicações. O controlador é executado como um daemon num nó do AKS e consome alguns dos recursos do nó, como CPU, memória e largura de banda de rede. Em ambientes maiores, pode considerar o seguinte:

• Descarregue parte deste encaminhamento de tráfego ou terminação TLS para um recurso de rede fora do cluster do AKS.
• Analise o tráfego de entrada para obter potenciais ataques.

Para essa camada adicional de segurança, uma firewall de aplicações Web (WAF) filtra o tráfego de entrada. Com um conjunto de regras, o Open Web Application Security Project (OWASP) observa ataques como scripting entre sites ou envenenamento por cookies. Gateway de Aplicação do Azure (atualmente em pré-visualização no AKS) é uma WAF que se integra com clusters do AKS, bloqueando estas funcionalidades de segurança antes de o tráfego chegar ao cluster e às aplicações do AKS.

Uma vez que outras soluções de terceiros também executam estas funções, pode continuar a utilizar investimentos ou conhecimentos existentes no seu produto preferido.

O balanceador de carga ou os recursos de entrada são executados continuamente no cluster do AKS e refinam a distribuição de tráfego. O Gateway de Aplicação pode ser gerido centralmente como um controlador de entrada com uma definição de recurso. Para começar, crie um controlador de entrada Gateway de Aplicação.

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

Orientação sobre melhores práticas

Utilize políticas de rede para permitir ou negar o tráfego para pods. Por predefinição, todo o tráfego é permitido entre pods num cluster. Para uma segurança melhorada, defina regras que limitam a comunicação do pod.

A política de rede é uma funcionalidade do Kubernetes disponível no AKS que lhe permite controlar o fluxo de tráfego entre pods. Permite ou nega o tráfego para o pod com base em definições como etiquetas atribuídas, espaço de nomes ou porta de tráfego. As políticas de rede são uma forma nativa da cloud de controlar o fluxo de tráfego dos pods. À medida que os pods são criados dinamicamente num cluster do AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.

Para utilizar a política de rede, ative a funcionalidade quando criar um novo cluster do AKS. Não pode ativar a política de rede num cluster do AKS existente. Planeie com antecedência para ativar a política de rede nos clusters necessários.

Nota

A política de rede só deve ser utilizada para nós e pods baseados em Linux no AKS.

Pode criar uma política de rede como um recurso do Kubernetes com um manifesto YAML. As políticas são aplicadas a pods definidos, com regras de entrada ou saída a definir o fluxo de tráfego.

O exemplo seguinte aplica uma política de rede a pods com a aplicação: etiqueta de back-end aplicada aos mesmos. A regra de entrada só permite o tráfego de pods com a aplicação: etiqueta de front-end .

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 utilizar políticas, veja Proteger o tráfego entre pods através de políticas de rede no Azure Kubernetes Service (AKS).

Ligar de forma segura aos nós através de um anfitrião bastion

Orientação sobre melhores práticas

Não exponha a conectividade remota aos nós do AKS. Crie um anfitrião bastion, ou jump box, numa rede virtual de gestão. Utilize o anfitrião bastion para encaminhar de forma segura o tráfego para o cluster do AKS para tarefas de gestão remota.

Pode concluir a maioria das operações no AKS com as ferramentas de gestão do Azure ou através do servidor da API do Kubernetes. Os nós do AKS só estão disponíveis numa rede privada e não estão ligados à Internet pública. Para ligar a nós e fornecer manutenção e suporte, encaminhe as ligações através de um anfitrião bastion ou jump box. Verifique se este anfitrião está numa rede virtual de gestão separada e em modo de peering seguro para a rede virtual do cluster do AKS.

Também deve proteger a rede de gestão do anfitrião bastion. Utilize um Azure ExpressRoute ou um gateway de VPN para ligar a uma rede no local e controlar o acesso através de grupos de segurança de rede.

Passos seguintes

Este artigo focou-se na conectividade e segurança da rede. Para obter mais informações sobre as noções básicas de rede no Kubernetes, veja Conceitos de rede para aplicações no Azure Kubernetes Service (AKS)