Compartilhar via

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

  • Artigo

Ao criar e gerenciar clusters no Serviço de Kubernetes do Azure (AKS), 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:

  • Comparar os modos de rede do kubenet e da CNI (Interface de Rede de Contêiner do Azure) no AKS.
  • Planeje o endereçamento de IP necessário e a conectividade.
  • Distribua o tráfego usando balanceadores de carga, controladores de entrada ou WAF (firewall do aplicativo Web).
  • Conecte-se com segurança a nós do cluster.

Escolha o modelo de rede apropriado

Orientação de melhor prática

Use a rede da CNI do Azure no AKS para integração com redes virtuais existentes ou redes locais. Esse modelo de rede permite maior separação de recursos e controles em um ambiente corporativo.

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 CNI do Azure: implementa em uma rede virtual e usa o plug-in Kubernetes da CNI do Azure. Pods recebem IPs individuais que podem rotear para outros serviços de rede ou a recursos locais.
  • Rede Kubenet: o Azure gerencia os recursos de rede virtual à medida que o cluster é implantado e usa o plug-in do Kubernetes kubenet.

A CNI do Azure e o kubenet são opções válidas para implantações de produção.

Rede CNI

CNI do Azure é um protocolo de fornecedor que permite que o runtime do contêiner faça solicitações para um provedor de rede. Ela atribui endereços IP para nós e pods e fornece recursos IPAM (gerenciamento de endereço IP) que você conecta às redes virtuais existentes do Azure. Cada nó e recurso de pod recebe um endereço IP na rede virtual do Azure. Não há necessidade de roteamento adicional para se comunicar com outros recursos ou serviços.

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

Notavelmente, a rede da CNI do Azure para produção permite a separação do controle e gerenciamento de recursos. De uma perspectiva de segurança, você geralmente deseja diferentes equipes para gerenciar e proteger esses recursos. Com a rede da CNI do Azure, você se conecta a recursos existentes do Azure, a recursos locais ou a outros serviços diretamente por meio de endereços IP atribuídos a cada pod.

Quando você usa a rede do CNI do Azure, o recurso de rede virtual fica em um grupo de recursos separado para o 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:

  • 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, em vez disso, você pode usar uma entidade de serviço.

Como cada nó e pod recebe seu próprio endereço IP, planeje os intervalos de endereços para as sub-redes do 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 você implantar.
    • Com as redes kubenet e CNI do Azure, 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 a 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 extras disponíveis na sub-rede atribuída.
    • Esse espaço de endereço extra é especialmente importante se você usa 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 os nós do Windows Server, confira Atualizar um pool de nós no AKS.

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

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

Para obter detalhes específicos sobre os limites e o dimensionamento para esses intervalos de endereços, confira 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, por exemplo:

  • Como os nós e pods são colocados em sub-redes IP diferentes, o encaminhamento de IP e UDR (roteamento definido pelo usuário) direcionam 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 emparelhamento com outras redes virtuais do Azure podem ser complexas.

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 teste ou desenvolvimento.
  • Sites simples com baixo tráfego.
  • Levantar e deslocar cargas de trabalho em contêineres.

Para implantações de produção, o kubenet e a CNI do Azure são opções válidas. Em ambientes que exigem a separação do controle e do gerenciamento, a CNI do Azure pode ser a opção preferencial. Além disso, o kubenet é adequado apenas para ambientes Linux nos quais 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 o kubenet. Como a rede da CNI do Azure, esses intervalos de endereços não devem se sobrepor uns aos outros nem a nenhuma rede associada ao cluster (redes virtuais, sub-redes, redes locais e emparelhadas).

Para obter os detalhes específicos sobre os limites e o dimensionamento para esses intervalos de endereços, confira Usar a rede kubenet com intervalos de endereços IP próprios no AKS.

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. Comparado a 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 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.

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

Há dois componentes para a entrada:

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

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

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 entrada

Um controlador de entrada é um daemon executado em um nó do AKS e observa as solicitações de entrada. Em seguida, o tráfego é distribuído com base em 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 precisam ser agendados em um nó do Linux. Indique que o recurso deve ser executado em um nó baseado em Linux usando um seletor de nó no manifesto do YAML ou na implantação do gráfico de Helm. Para obter mais informações, confira Usar seletores de nó para controlar em que local os pods são agendados no AKS.

Entrada com o complemento de roteamento de aplicativos

O complemento de roteamento de aplicativos é a maneira recomendada para configurar um controlador de entrada no AKS. O complemento do roteamento de aplicativos é um controlador de entrada totalmente gerenciado para o Serviço de Kubernetes do Azure (AKS) que 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 o DNS do Azure para gerenciamento de zona pública e privada.

  • Terminação SSL com certificados armazenados no Azure Key Vault.

Para obter mais informações sobre o complemento de roteamento de aplicativos, consulte Entrada NGINX gerenciada com o complemento de roteamento de aplicativos.

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

Orientação de melhor prática

Para verificar o tráfego de entrada quanto a ataques potenciais, use o WAF (firewall do aplicativo Web), como Barracuda WAF para Azure ou Gateway de Aplicativo do Azure. Esses recursos de rede mais avançados também podem rotear o tráfego além de conexões HTTP e HTTPS ou da terminação TLS básica.

Geralmente, um controlador de entrada é um recurso Kubernetes no cluster do AKS que distribui o tráfego para serviços e aplicativos. O controlador é executado como um daemon em um nó do AKS e 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.

Um firewall do aplicativo web (WAF) como o Gateway de Aplicativo do Azure pode proteger e distribuir o tráfego para seu cluster do AKS

Para essa camada extra de segurança, um WAF (firewall do aplicativo Web) filtra o tráfego de entrada. Com um conjunto de regras, o OWASP (Open Web Application Security Project) inspeciona ataques, como cross-site scripting ou envenenamento por cookie. O Gateway de Aplicativo do Azure (atualmente em versão prévia no AKS) é um WAF que é integrado aos clusters do AKS, bloqueando esses recursos de segurança antes que o tráfego alcance o cluster do AKS e os aplicativos.

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

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

Observação

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 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 as políticas, confira Proteger o tráfego entre os pods usando as políticas de rede no AKS (Serviço de Kubernetes do Azure).

Conecte-se com segurança a nós por meio de um host bastião

Orientação de melhor prática

Não exponha a conectividade remota aos seus nós do AKS. Crie um host bastião, ou jump box, em uma rede virtual de gerenciamento. Use o host de bastião para rotear o tráfego com segurança no cluster do 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 do AKS não 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, encaminhe suas conexões por meio de um bastion host ou jump box. Verifique se o host está em uma rede virtual de gerenciamento separada conectada com a rede virtual do cluster do AKS por meio de um peering seguro.

Conecte-se aos nós do AKS usando um host bastião jump box

Você também deve proteger a rede de gerenciamento do bastion host. Use um Azure ExpressRoute ou gateway VPN para se conectar a uma rede local e controlar o acesso usando 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 conceitos básicos de rede no Kubernetes, consulte Conceitos de rede para aplicativos no Serviço de Kubernetes do Azure (AKS)