Usar o Firewall do Azure para ajudar a proteger um cluster do AKS (Serviço de Kubernetes do Azure)

Firewall do Azure

AKS (Serviço de Kubernetes do Azure)

Link Privado do Azure

Rede Virtual do Azure

Azure DevOps

Este guia descreve como criar um cluster do AKS privado em uma topologia de rede hub-and-spoke usando o Terraform e o Azure DevOps. O Firewall do Azure é usado para inspecionar o tráfego de e para o cluster do Serviço de Kubernetes do Azure (AKS). O cluster é hospedado por uma ou mais redes virtuais spoke emparelhadas à rede virtual do hub.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Os módulos Terraform são usados para implantar uma nova rede virtual que tem quatro sub-redes que hospedam:

O cluster AKS (AksSubnet).
Uma máquina virtual jumpbox (VM) e pontos de extremidade privados (VmSubnet).
WAF2 do Gateway de Aplicativo (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

O cluster do AKS usa uma identidade gerenciada definida pelo usuário para criar recursos adicionais, como balanceadores de carga e discos gerenciados no Azure. Os módulos Terraform permitem que você opcionalmente implante um cluster AKS que tenha estes recursos:

O cluster do AKS é composto pelos seguintes pools:

Um pool de nós do sistema que hospeda apenas os pods e os serviços críticos do sistema
O pool de nós do usuário que hospeda as cargas de trabalho e os artefatos do usuário

Uma VM (máquina virtual) é implantada na mesma rede virtual que hospeda o cluster do AKS. Quando você implanta o AKS como um cluster privado, essa VM pode ser usada pelos administradores do sistema para gerenciar o cluster por meio da ferramenta de linha de comando do Kubernetes. Os logs de diagnóstico de inicialização da VM são armazenados em uma conta do Armazenamento do Azure.

Um host do Azure Bastion fornece conectividade SSH de segurança aprimorada para a VM de caixa de salto sobre SSL. O ACR (Registro de Contêiner do Azure) é usado para criar, armazenar e gerenciar imagens de contêiner e artefatos (como gráficos do Helm).

O AKS não oferece uma solução integrada para proteger o tráfego de entrada e saída entre o cluster e as redes externas.

Por esse motivo, a arquitetura apresentada neste artigo inclui um Firewall do Azure que controla o tráfego de entrada e saída usando regras DNAT, regras de rede e regras de aplicativos. O firewall também protege cargas de trabalho com filtragem baseada em inteligência de ameaças. O Firewall do Azure e o Bastion são implantados em uma rede virtual de hub emparelhada com a rede virtual que hospeda o cluster AKS privado. Uma tabela de rotas e rotas definidas pelo usuário encaminham o tráfego de saída do cluster AKS para o Firewall do Azure.

Observação

É altamente recomendável que você use a SKU Premium do Firewall do Azure, pois ela fornece proteção avançada contra ameaças.

Um cofre de chaves é usado como um repositório de segredos pelas cargas de trabalho executadas no AKS (Serviço de Kubernetes do Azure) para recuperar chaves, certificados e segredos por meio de Microsoft Entra Workload ID, Driver CSI do armazenamento de segredos ou Dapr. O Link Privado do Azure permite que as cargas de trabalho do AKS acessem os serviços de PaaS do Azure, como o Azure Key Vault, em um ponto de extremidade privado na rede virtual.

A topologia inclui pontos de extremidade privados e zonas DNS privadas para estes serviços:

Há um link de rede virtual entre a rede virtual que hospeda o cluster AKS e as zonas DNS privadas descritas anteriormente.

Um workspace do Log Analytics é usado para coletar os logs de diagnóstico e as métricas dos serviços do Azure.

Componentes

Firewall do Azure: um serviço de segurança de firewall de rede inteligente e nativo de nuvem que fornece proteção contra ameaças para suas cargas de trabalho de nuvem em execução no Azure. É um firewall como serviço totalmente com estado com alta disponibilidade interna e escalabilidade de nuvem irrestrita. Ele fornece inspeção de tráfego de leste a oeste e de norte a sul.
O Registro de Contêiner do Azure é um serviço gerenciado do Registro do Docker privado baseado no Registro do Docker 2.0 de código aberto. Use registros de contêiner do Azure com seus pipelines existentes de desenvolvimento e implantação de contêiner ou use Tarefas do Registro de Contêiner do Azure para criar imagens de contêiner no Azure.
O Azure Kubernetes Service simplifica a implantação de um cluster do Kubernetes gerenciado no Azure transferindo a sobrecarga operacional para o Azure. Como um serviço de Kubernetes hospedado, o Azure lida com tarefas críticas como o monitoramento de integridade e a manutenção. Como os mestres do Kubernetes são gerenciados pelo Azure, você só gerencia e mantém os nós de agente.
O Azure Key Vault armazena e controla com segurança o acesso a segredos como chaves de API, senhas, certificados e chaves de criptografia com segurança aprimorada. O cofre de chaves também permite que você provisione, gerencie e implante com facilidade certificados TLS/SSL para uso com o Azure e seus recursos internos conectados.
O Azure Bastion é uma PaaS (plataforma como serviço) totalmente gerenciada que você provisiona na sua rede virtual. O Azure Bastion fornece conectividade do Remote Desktop Protocol (RDP) e Secure Shell (SSH) de segurança aprimorada às VMs na sua rede virtual, diretamente do portal do Azure via TLS.
As Máquinas Virtuais do Azure fornecem recursos de computação escalonáveis sob demanda que oferecem a flexibilidade da virtualização.
A Rede Virtual do Azure é o componente fundamental para redes privadas do Azure. A Rede Virtual permite recursos do Azure, como VMs, para se comunicar entre si, Internet e redes locais, tudo com conexões com segurança aprimorada. Uma Rede Virtual do Azure é semelhante a uma rede tradicional local, mas inclui os benefícios da infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento.
Os adaptadores de rede virtual permitem que as VMs do Azure se comuniquem com a Internet, com o Azure e com os recursos locais. Você pode adicionar várias placas de adaptador de rede a uma VM do Azure, de modo que as VMs filho possam ter dispositivos de adaptador de rede dedicados e endereços IP próprios.
Os discos gerenciados do Azure fornecem volumes de armazenamento de nível de bloco que o Azure gerencia nas VMs do Azure. Ultradiscos, unidades de estado sólido (SSDs) premium, SSDs padrão e unidades de disco rígido (HDDs) padrão estão disponíveis.
O Armazenamento de Blobs do Azure é uma solução de armazenamento de objetos para a nuvem. O Armazenamento de Blobs é otimizado para armazenar grandes quantidades de dados não estruturados.
O Link Privado permite acessar os serviços Azure PaaS (por exemplo, Blob Storage e Key Vault) através de um ponto final privado na sua rede virtual. Você também pode usá-lo para acessar serviços hospedados no Azure que você possui ou que são fornecidos por um parceiro da Microsoft.

Alternativas

Você pode usar um firewall de terceiros do Azure Marketplace em vez do Firewall do Azure. Se você fizer isso, é sua responsabilidade configurar corretamente o firewall para inspecionar e permitir ou negar o tráfego de entrada e saída do cluster AKS.

Detalhes do cenário

Os clusters AKS são implantados em uma rede virtual, que pode ser gerenciada ou personalizada. Independentemente disso, o cluster tem dependências de saída em serviços fora da rede virtual. Para fins operacionais e de gerenciamento, os nós do cluster AKS precisam acessar portas específicas e nomes de domínio totalmente qualificados (FQDNs) associados a essas dependências de saída. Isso inclui o acesso ao servidor da API do Kubernetes do seu próprio cluster, o download e a instalação de componentes do cluster e a extração de imagens de contêineres do Registro de Contêineres da Microsoft. Essas dependências de saída são definidas com FQDNs e não têm endereços estáticos, impossibilitando o bloqueio do tráfego de saída com o uso de grupos de segurança de rede. Portanto, os clusters AKS têm acesso irrestrito à Internet de saída (egresso) por padrão para permitir que os nós e os serviços acessem recursos externos conforme necessário.

No entanto, em um ambiente de produção, geralmente é desejável proteger o cluster do Kubernetes contra a exfiltração de dados e outros tráfegos de rede indesejados. Todo o tráfego de rede, tanto de entrada quanto de saída, deve ser controlado com base em regras de segurança. Para isso, o tráfego de saída precisa ser restrito e, ao mesmo tempo, permitir o acesso às portas e aos endereços necessários para as tarefas de manutenção de rotina do cluster, dependências de saída e requisitos de carga de trabalho.

Uma solução simples é usar um dispositivo de firewall que controle o tráfego de saída com base nos nomes de domínio. Um firewall cria uma barreira entre uma rede confiável e a Internet. Use o Firewall do Azure para restringir o tráfego de saída com base no FQDN, no protocolo e na porta do destino, fornecendo controle de tráfego de saída rigoroso. Também permite a listagem de permissões para FQDNs associados às dependências de saída de um cluster AKS, o que não é possível com os Grupos de segurança de rede. Além disso, a filtragem baseada em inteligência contra ameaças no Firewall do Azure implantado em uma rede de perímetro compartilhado pode controlar o tráfego de entrada e aumentar a segurança. Essa filtragem pode gerar alertas e negar o tráfego de e para endereços IP e domínios reconhecidamente mal-intencionados.

Você pode criar um cluster AKS privado em uma topologia de rede hub-and-spoke usando o Terraform e o Azure DevOps. O Firewall do Azure é usado para inspecionar o tráfego de e para o cluster do Serviço de Kubernetes do Azure (AKS). O cluster é hospedado por uma ou mais redes virtuais spoke emparelhadas à rede virtual do hub.

O Firewall do Azure agora suporta três SKUs diferentes para atender a uma ampla variedade de casos de uso e preferências do cliente:

O Firewall do Azure Premium é recomendado para segurança aplicativos altamente confidenciais (como processamento de pagamentos). Ele suporta recursos avançados de proteção contra ameaças, como malware e inspeção TLS.
O Firewall do Azure Standard é recomendado para clientes que procuram um firewall de camada 3 a camada 7 e que precisam de escalonamento automático para lidar com períodos de pico de tráfego de até 30 Gbps. Ele suporta recursos corporativos como inteligência contra ameaças, proxy DNS, DNS personalizado e categorias da Web.
O Firewall do Azure Basic é recomendado para clientes SMB com necessidades de taxa de transferência de menos de 250 Mbps.

A tabela a seguir mostra os recursos dos três SKUs do Firewall do Azure. Para obter mais informações, consulte Preços do Firewall do Azure.

Captura de tela que mostra os recursos das três SKUs do Firewall do Azure

Por padrão, os clusters do AKS têm acesso irrestrito à Internet de saída. Este nível de acesso à rede permite que nós e serviços executados no cluster AKS acessem recursos externos conforme necessário. Se quiser restringir o tráfego de saída, um número limitado de portas e endereços precisar estar acessível para manter a integridade das tarefas de manutenção de cluster. A maneira mais fácil de fornecer segurança para o tráfego de saída de um cluster Kubernetes como o AKS é usar um firewall de software que possa controlar o tráfego de saída com base em nomes de domínio. O Firewall do Azure pode restringir o tráfego HTTP e HTTPS de saída com base no nome de domínio totalmente qualificado (FQDN) do destino. Você também pode configurar o firewall e as regras de segurança para permitir as portas e os endereços necessários. Para obter mais informações, confira Controlar o tráfego de saída para nós de cluster no AKS.

Da mesma forma, você pode controlar o tráfego de entrada e aumentar a segurança habilitando a filtragem baseada em inteligência contra ameaças em um Firewall do Azure implantado em uma rede de perímetro compartilhado. Essa filtragem pode gerar alertas e negar o tráfego proveniente e destinado a endereços IP e domínios mal-intencionados conhecidos.

Possíveis casos de uso

Esse cenário aborda a necessidade de melhorar a segurança do tráfego de entrada e saída de e para um cluster do Kubernetes.

Evitar roteamento assimétrico

Nesta solução, o Firewall do Azure é implantado em uma rede virtual de hub e o cluster AKS privado é implantado em uma rede virtual de spoke. O Firewall do Azure usa coleções de regras de rede e de aplicativo para controlar o tráfego de saída. Nessa situação, você precisa configurar o tráfego de entrada para qualquer ponto de extremidade público exposto por qualquer serviço em execução no AKS para entrar no sistema por meio de um dos endereços IP públicos usados pelo Firewall do Azure.

Os pacotes chegam no endereço IP público do firewall, mas retornam para o firewall por meio do endereço IP privado (usando a rota padrão). Isso não é um problema. Para evitá-lo, crie outra rota definida pelo usuário para o endereço IP público do firewall, conforme mostrado no diagrama a seguir. Pacotes que vão para o endereço IP público do firewall são roteadas pela Internet. Essa configuração evita o uso da rota padrão para o endereço IP privado do firewall.

Para rotear o tráfego de suas cargas de trabalho AKS para o Firewall do Azure na rede virtual de hub, você precisa:

Crie e associe uma tabela de rotas a cada sub-rede que hospeda os nós de trabalho do cluster.
Crie uma rota definida pelo usuário para encaminhar o tráfego do CIDR 0.0.0.0/0 para o endereço IP privado do Firewall do Azure. Especifique o Dispositivo virtual para o Tipo de próximo salto.

Para saber mais sobre isso, confira Tutorial: Implantar e configurar o Firewall do Azure usando o portal do Azure.

Para saber mais, veja:

Implantar cargas de trabalho em um cluster AKS privado ao usar o Azure DevOps

Se você usar o Azure DevOps, observe que não é possível usar agentes hospedados pela Microsoft do Azure DevOps para implantar suas cargas de trabalho em um cluster AKS privado. Eles não têm acesso ao seu servidor de API. Para implantar cargas de trabalho em seu cluster AKS privado, você precisa provisionar e usar um agente auto-hospedado do Azure DevOps na mesma rede virtual que seu cluster AKS privado ou em uma rede virtual emparelhada. No último caso, certifique-se de criar um link de rede virtual entre a zona DNS privada do cluster AKS no grupo de recursos do nó e a rede virtual que hospeda o agente auto-hospedado do Azure DevOps.

Você pode implantar um único agente de DevOps do Azure Windows ou Linux em uma máquina virtual ou pode usar um Conjunto de Dimensionamento de Máquina Virtual. Para obter mais informações, confira Agentes dos conjuntos de dimensionamento de máquinas virtuais do Azure. Como alternativa, você pode configurar um agente auto-hospedado no Azure Pipelines para ser executado dentro de um contêiner Windows Server Core (para hosts Windows) ou contêiner Ubuntu (para hosts Linux) com o Docker. Implante-o como um pod com uma ou várias réplicas em seu cluster AKS privado. Para saber mais, veja:

Se as sub-redes que hospedam os pools de nós do cluster AKS privado estiverem configuradas para rotear o tráfego de saída para um Firewall do Azure por meio de uma tabela de rotas e rota definida pelo usuário, crie o aplicativo e as regras de rede adequadas. Essas regras precisam permitir que o agente acesse sites externos para baixar e instalar ferramentas como Docker, Kubectl, Azure CLI e Helm na máquina virtual do agente. Para obter mais informações, consulte Executar um agente auto-hospedado no Docker.

Como alternativa, você pode configurar um MDP (Managed DevOps Pool, pool de DevOps gerenciado) na rede virtual que hospeda o cluster AKS ou em uma rede virtual emparelhada. Os pools de DevOps gerenciados permitem que as equipes de desenvolvimento criem pools de agentes do Azure DevOps adaptados às suas necessidades específicas. Ele implementa as práticas recomendadas de segurança, fornece opções para equilibrar custo e desempenho, oferece caminhos para cenários comuns e reduz significativamente o tempo gasto na criação e manutenção de pools personalizados. Para obter mais informações, consulte Visão geral da arquitetura dos pools de DevOps gerenciados da Microsoft.

Você pode adicionar agentes de um pool de DevOps gerenciado na sua rede virtual, permitindo que os pipelines de CI/CD interajam com o servidor da API do Kubernetes do seu cluster AKS privado e acessem recursos do Azure, como o Registro de Contêineres do Azure, que têm acesso à rede pública desativado e só podem ser acessados por meio de um ponto de extremidade privado definido na mesma rede virtual ou em uma rede emparelhada. Para obter mais informações, consulte a documentação Configurar rede de pools de DevOps gerenciados.

Usar o Firewall do Azure na frente de um Load Balancer Padrão público

As definições de recursos nos módulos Terraform usam meta-argumento do ciclo de vida para personalizar ações quando os recursos do Azure são alterados fora do controle Terraform. O argumento ignore_changes é usado para instruir o Terraform a ignorar atualizações de determinadas propriedades de recurso, como tags. A definição de recurso da Política de Firewall do Azure contém um bloco de ciclo de vida para impedir que o Terraform atualize o recurso quando uma coleção de regras ou uma única regra é criada, atualizada ou excluída. Da mesma forma, a Tabela de Rotas do Azure contém um bloco de ciclo de vida para impedir que o Terraform atualize o recurso quando uma rota definida pelo usuário é criada, excluída ou atualizada. Isso permite que você gerencie o DNAT, o aplicativo e as regras de rede de uma Política de Firewall do Azure e as rotas definidas pelo usuário de uma Tabela de Rotas do Azure fora do controle Terraform.

O exemplo associado a este artigo contém um pipeline de CD de DevOps do Azure que mostra como implantar uma carga de trabalho em um cluster AKS privado usando um pipeline de DevOps do Azure executado em um agente autohospedado. O exemplo implanta o aplicativo Web de gerenciamento de projetos Redmine Bitnami usando um gráfico Helm público. Este diagrama mostra a topologia de rede do exemplo:

Veja o fluxo de mensagem:

Uma solicitação para o aplicativo Web hospedado no AKS é enviada a um IP público exposto pelo Firewall do Azure por meio de uma configuração de IP público. Tanto o IP público quanto a configuração de IP público são dedicados a essa carga de trabalho.
Uma regra DNAT do Firewall do Azure converte o endereço IP público e a porta do Firewall do Azure para o IP público e a porta usados pela carga de trabalho no Load Balancer Padrão público do Kubernetes do cluster AKS no grupo de recursos do nó.
O balanceador de carga envia a solicitação para um dos pods de serviço do Kubernetes que está sendo executado em um dos nós de agente do cluster AKS.
A mensagem de resposta é enviada de volta ao chamador original por meio de uma rota definida pelo usuário. O IP público do Firewall do Azure é o prefixo de endereço e Internet é o tipo de próximo salto.
Qualquer chamada de saída iniciada pela carga de trabalho é roteada para o endereço IP privado do Firewall do Azure pela rota padrão definida pelo usuário. 0.0.0.0/0 é o prefixo de endereço e o Dispositivo virtual é o tipo de próximo salto.

Para obter mais informações, consulte Usar o Firewall do Azure na frente do Load Balancer Padrão Público do cluster AKS.

Usar o Firewall do Azure na frente de um Load Balancer Padrão interno

No exemplo associado a este artigo, um aplicativo ASP.NET Core é hospedado como um serviço por um cluster AKS e liderado por um controlador de entrada NGINX. O controlador de entrada NGINX é exposto por meio de um balanceador de carga interno que tem um endereço IP privado na rede virtual spoke que hospeda o cluster AKS. Para obter mais informações, consulte Criar um controlador de entrada para uma rede virtual interna no AKS. Quando você implanta um controlador de entrada NGINX, ou mais geralmente um serviço LoadBalancer ou ClusterIP, com a service.beta.kubernetes.io/azure-load-balancer-internal: "true" anotação na seção de metadados, um load balancer padrão interno chamado kubernetes-internal é criado no grupo de recursos do nó. Para obter mais informações, consulte Usar um Load Balancer interno com AKS. Conforme mostrado no diagrama a seguir, o aplicativo Web de teste é exposto pelo Firewall do Azure por meio de um IP público dedicado do Azure.

Veja o fluxo de mensagem:

Uma solicitação para o aplicativo Web hospedado no AKS é enviada a um IP público exposto pelo Firewall do Azure por meio de uma configuração de IP público. Tanto o IP público quanto a configuração de IP público são dedicados a essa carga de trabalho.
Uma regra DNAT do Firewall do Azure converte o IP público e a porta do Firewall do Azure para o IP e a porta privados usados pelo controlador de entrada NGINX no Load Balancer Padrão interno do cluster AKS no grupo de recursos do nó.
A solicitação é enviada pelo balanceador de carga interno para um dos pods de serviço do Kubernetes que está sendo executado em um dos nós de agente do cluster AKS.
A mensagem de resposta é enviada de volta ao chamador original por meio de uma rota definida pelo usuário. 0.0.0.0/0 é o prefixo de endereço e o Dispositivo virtual é o tipo de próximo salto.
Qualquer chamada de saída iniciada pela carga de trabalho é roteada para o endereço IP privado da rota definida pelo usuário.

Para obter mais informações, consulte Usar o Firewall do Azure na frente de um Load Balancer Padrão interno.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Algumas das considerações a seguir são recomendações gerais que não são específicas para usar o Firewall do Azure para melhorar a proteção de um cluster AKS. Acreditamos que são requisitos essenciais desta solução. Isso se aplica a considerações sobre segurança, desempenho, disponibilidade e confiabilidade, armazenamento, agendador, malha de serviço e monitoramento.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

A plataforma Azure fornece proteção aprimorada contra várias ameaças, como invasão de rede e ataques distribuídos de negação de serviço (DDoS). Você deve usar um WAF (Web Application Firewall) para fornecer proteção para quaisquer aplicativos e serviços Web hospedados no AKS que exponham um ponto de extremidade HTTPS público. Você precisa fornecer proteção contra ameaças comuns, como injeção de SQL, scripts entre sites e outras explorações da Web. Para fazer isso, use regras do Open Web Application Security Project (OWASP) e regras personalizadas. O Firewall de Aplicativo Web do Azure fornece proteção centralizada para seus aplicativos Web contra vulnerabilidades e explorações comuns. Você pode implantar o Azure WAF com o Gateway de Aplicativo do Azure, o Azure Front Door e a Rede de Entrega de Conteúdo do Azure.

Os ataques DDoS estão entre as maiores preocupações de disponibilidade e segurança enfrentadas pelas organizações que estão movendo seus aplicativos para a nuvem. Um ataque de DDoS tenta esgotar os recursos de um aplicativo, fazendo com que o aplicativo fique indisponível para usuários legítimos. Os ataques de DDoS podem ser direcionados a qualquer ponto de extremidade publicamente acessível pela Internet. Cada propriedade no Azure inclui proteção por meio da proteção da infraestrutura Azure DDoS sem nenhum custo extra. A escala e a capacidade da rede implantada globalmente do Azure fornecem defesa aprimorada contra ataques de camada de rede comum por meio de monitoramento de tráfego sempre ativo e mitigação em tempo real. A Proteção contra DDoS da infraestrutura não exige nenhuma alteração nas configurações do usuário ou no aplicativo do usuário. Isso ajuda a proteger todos os serviços do Azure, incluindo serviços PaaS, como o DNS do Azure.

A Proteção de Rede contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, oferece recursos aprimorados de mitigação de DDoS para a defesa contra ataques de DDoS. Você deve habilitar a Proteção de Rede contra DDOS do Azure em qualquer rede virtual de perímetro.

A seguir estão algumas considerações de segurança adicionais:

Crie um ponto de extremidade privado para qualquer serviço de PaaS usado pelas cargas de trabalho do AKS, como o Key Vault, o Barramento de Serviço ou o Banco de Dados SQL do Azure. O tráfego entre os aplicativos e esses serviços não é exposto à Internet pública. O tráfego entre a rede virtual de cluster AKS e uma instância de um serviço PaaS por meio de um ponto de extremidade privado percorre a rede de backbone da Microsoft, mas a comunicação não passa pelo Firewall do Azure. Esse mecanismo proporciona maior segurança e melhor proteção contra vazamento de dados. Para obter mais informações, confira O que é o Link Privado do Azure?.
Ao usar o Gateway de Aplicativo na frente do cluster AKS, use uma Política de Firewall de Aplicativo Web para ajudar a proteger cargas de trabalho voltadas para o público executadas no AKS contra ataques.
Use políticas de rede para separar e ajudar a proteger as comunicações entre serviços controlando os componentes que podem se comunicar entre si. Por padrão, todos os pods de um cluster de Kubernetes podem enviar e receber tráfego sem limitações. Para melhorar a segurança, pode utilizar políticas de rede Azure ou políticas de rede Calico para definir regras que controlam o fluxo de tráfego entre diferentes microsserviços. Para obter mais informações, confira Política de rede.
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 bastion para rotear o tráfego para seu cluster AKS.
Considere o uso de um cluster privado do AKS no seu ambiente de produção ou, pelo menos, a proteção do acesso ao servidor de API usando intervalos de endereços IP autorizados no AKS. Quando você usa intervalos de endereços IP autorizados em um cluster público, permita todos os endereços IP de saída na coleção de regras de rede do Firewall do Azure. As operações no cluster consomem o servidor de API do Kubernetes.
Se você habilitar o proxy DNS no Firewall do Azure, o Firewall do Azure poderá processar e encaminhar consultas DNS de uma ou mais redes virtuais para um servidor DNS que você escolher. Essa funcionalidade é essencial e necessária para uma filtragem de FQDN confiável em regras de rede. Você pode habilitar o proxy DNS nas configurações da Política de Firewall e do Firewall do Azure. Para saber mais sobre logs de proxy DNS, consulte Log e métricas do Firewall do Azure.
Ao usar o Firewall do Azure na frente do Gateway de Aplicativo, você pode configurar seu recurso de entrada do Kubernetes para expor cargas de trabalho via HTTPS e usar um subdomínio e um certificado digital separados para cada locatário. O AGIC (Controlador de Entrada do Gateway de Aplicativo) vai configurar automaticamente o ouvinte do Gateway de Aplicativo do Azure para terminação SSL.
Você pode usar o Firewall do Azure na frente de um proxy de serviço, como o controlador de entrada NGINX. Esse controlador fornece proxy reverso, roteamento de tráfego configurável e terminação de TLS para serviços do Kubernetes. Os recursos de entrada de Kubernetes são usados para configurar as regras de entrada e as rotas para os serviços de Kubernetes individuais. Ao usar um controlador de entrada e regras de entrada, você pode usar um único endereço IP para rotear o tráfego para vários serviços em um cluster do Kubernetes. Você pode gerar os certificados TLS usando uma autoridade de certificação reconhecida. Alternativamente, você pode usar o 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. Para mais informações confira Criar um controlador de entrada HTTPS e usar seus próprios certificados TLS no AKS.
A coordenação estrita entre o operador do Firewall do Azure e as equipes de cluster e carga de trabalho é necessária tanto para a implantação inicial do cluster quanto de forma contínua à medida que a carga de trabalho e as necessidades do cluster evoluem. Isso é especialmente verdadeiro quando você configura os mecanismos de autenticação, como OAuth 2.0 e OpenID Connect, que são usados por cargas de trabalho para autenticar seus clientes.
Use as seguintes diretrizes para ajudar a proteger o ambiente descrito neste artigo:

Disponibilidade e confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

As considerações de disponibilidade e confiabilidade aqui não são específicas para multilocação no AKS. Acreditamos que são requisitos essenciais desta solução. Considere os seguintes métodos para otimizar a disponibilidade do seu cluster e suas cargas de trabalho do AKS.

Resiliência entre regiões

Durante a implantação, você pode configurar o Firewall do Azure para abranger várias zonas de disponibilidade para maior disponibilidade. Para obter porcentagens de tempo de atividade, consulte o SLA do Firewall do Azure. Você também pode associar o Firewall do Azure a uma zona específica por uma questão de proximidade, embora essa configuração afete o SLA. Não há custo extra para um firewall implantado em uma zona de disponibilidade, incluindo transferências de dados entre zonas de disponibilidade.
Considere implantar os pools de nós do cluster AKS em todas as zonas de disponibilidade em uma região. Use um Load Balancer Padrão do Azure ou um Gateway de Aplicativo na frente dos pools de nós. Essa topologia fornece maior resiliência, no caso de uma interrupção de um só datacenter. Os nós de cluster são distribuídos entre vários datacenters, em três zonas de disponibilidade separadas de uma região.
Habilite a redundância de zona no Registro de Contêiner do Azure para obter alta disponibilidade e resiliência entre regiões.
Use as restrições de propagação de topologia de pod para controlar como os pods são distribuídos pelo cluster do AKS entre os domínios de falha, como regiões, zonas de disponibilidade e nós.
Considere o uso do SLA de tempo de atividade para clusters do AKS que hospedam cargas de trabalho críticas. O SLA de tempo de atividade é um recurso opcional usado para habilitar um SLA superior com suporte financeiro em um cluster. O SLA de tempo de atividade garante alta disponibilidade do ponto de extremidade do servidor de API do Kubernetes, para clusters que usam zonas de disponibilidade. Você também pode usá-lo para clusters que não usam zonas de disponibilidade, mas o SLA é menor. Para obter detalhes do SLA, consulte SLA de tempo de atividade. O AKS usa réplicas de nó mestre em domínios de atualização e de falha para garantir que os requisitos de SLA sejam atendidos.

Recuperação de desastre e continuidade dos negócios

Considere a possibilidade de implantar sua solução em, pelo menos, duas regiões emparelhadas do Azure em uma geografia. Use o load balancer global, como o Gerenciador de Tráfego do Azure ou o Azure Front Door, com um método de roteamento ativo/ativo ou ativo/passivo para garantir a continuidade dos negócios e a recuperação de desastre (DR).
O Firewall do Azure é um serviço regional. Se você implantar sua solução em duas ou mais regiões, precisará criar um Firewall do Azure em cada região. Você pode criar uma Política de Firewall do Azure global para incluir regras impostas pela organização que se aplicam a todos os hubs regionais. Você pode usar essa política como uma política pai para políticas regionais do Azure. As políticas criadas com políticas pai não vazias herdam todas as coleções de regras da política pai. As coleções de regras de rede herdadas de uma política pai sempre são priorizadas acima das coleções de regras de rede que são definidas como parte de sua nova política. A mesma lógica se aplica às coleções de regras de aplicativo. No entanto, as coleções de regras de rede são sempre processadas antes de coleções de regras de aplicativo, independentemente da herança. Para obter mais informações sobre políticas Standard e Premium, consulte Visão geral da política do Azure Firewall Manager.
Certifique-se de criar scripts, documentar e testar periodicamente qualquer processo de failover regional em um ambiente de controle de qualidade. Isso ajuda a evitar problemas imprevisíveis se um serviço principal for afetado por uma interrupção na região principal. Esses testes também verificam se a abordagem de DR atende às metas de RPO/RTO, em conjunto com intervenções e processos manuais eventuais que sejam necessários para um failover.
Certifique-se de testar os procedimentos de failback para validar se eles funcionam conforme o esperado.
Armazene suas imagens de contêiner no Registro de Contêiner. Replicar geograficamente o registro para cada região AKS. Para mais informações, confira Replicação geográfica no Registro de Contêiner do Azure.
Se possível, evite armazenar o estado do serviço no contêiner. Em vez disso, utilize um Azure PaaS que suporte a replicação multirregional.
Se utilizar o Armazenamento do Azure, prepare e teste um processo para migrar o seu armazenamento da região primária para a região de backup.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

DevOps

Implante suas cargas de trabalho no AKS usando um gráfico Helm em um pipeline de integração contínua e entrega contínua (CI/CD). Use um sistema de DevOps como GitHub Actions ou Azure DevOps. Para obter mais informações, confira Build e implantação no Serviço de Kubernetes do Azure.
Para testar adequadamente um aplicativo antes de disponibilizá-lo aos usuários, use testes A/B e implantações canário no gerenciamento do ciclo de vida do aplicativo. Há várias técnicas que você pode usar para dividir o tráfego entre diferentes versões do mesmo serviço. Como alternativa, você pode usar as funcionalidades de divisão de tráfego fornecidas por uma implementação de malha de serviço. Para obter mais informações, consulte Linkerd Traffic Split e Istio Traffic Management.
Use o Registro de Contêiner do Azure ou outro registro de contêiner (como o Docker Hub) para armazenar as imagens privadas do Docker implantadas no cluster. O AKS pode se autenticar no Registro de Contêiner do Azure por meio da identidade do Microsoft Entra.
Teste a entrada e a saída em suas cargas de trabalho em um ambiente de pré-produção separado que espelha a topologia de rede e as regras de firewall do ambiente de produção. Uma estratégia de distribuição em estágios ajudará você a detectar quaisquer problemas de rede ou segurança antes de lançar um novo recurso ou regra de rede em produção.

Monitoramento

Diretrizes: o Firewall do Azure é integrado ao Azure Monitor para registrar em log o tráfego de entrada e de saída processado pelo firewall. Para obter mais informações, confira Filtragem baseada em inteligência contra ameaças do Firewall do Azure.

As considerações de monitoramento a seguir não são específicas para multilocação no AKS, mas acreditamos que são requisitos essenciais para essa solução.

Use Insights de contêiner para monitorar o status de integridade do cluster e das cargas de trabalho do AKS.
Configure todos os serviços de PaaS (como o Registro de Contêiner e o Cofre de Chaves) para coletar logs e métricas de diagnóstico.

Otimização de custo

O custo dessa arquitetura resultante depende dos aspectos de configuração, como o seguinte:

Camadas de serviço
Escalabilidade, ou seja, o número de instâncias alocadas dinamicamente por serviços para dar suporte a uma demanda específica
Scripts de automação
Seu nível de recuperação de desastre

Depois de avaliar esses detalhes de configuração, use a Calculadora de Preços do Azure para estimar seus custos. Para obter mais opções de otimização de preços, confira Princípios da otimização de custo no Microsoft Azure Well-Architected Framework.

Implantar este cenário

O código-fonte desse cenário está disponível no GitHub. Essa solução é de código aberto e é fornecida com uma Licença MIT.

Pré-requisitos

Para implantações online, você precisa de uma conta do Azure. Crie uma conta gratuita do Azure, caso ainda não tenha uma, antes de começar. Você precisa atender a esses requisitos antes de implantar módulos Terraform usando o Azure DevOps:

Armazene o arquivo de estado Terraform em uma conta de armazenamento do Azure. Para obter mais informações sobre como usar uma conta de armazenamento para armazenar o estado Terraform remoto, o bloqueio de estado e a criptografia em repouso, consulte Armazenar o estado Terraform no Armazenamento do Azure.
Crie um projeto do Azure DevOps. Para obter mais informações, consulte Criar um projeto no Azure DevOps.
Crie uma conexão de serviço do Azure DevOps com sua assinatura do Azure. Você pode usar a Autenticação da Entidade de Serviço (SPA) ou uma identidade de serviço gerenciado do Azure ao criar a conexão de serviço. Em ambos os casos, certifique-se de que a entidade de serviço ou a identidade gerenciada usada pelo Azure DevOps para se conectar à sua assinatura do Azure tenha a função de proprietário atribuída em toda a assinatura.

Implantação no Azure

Tenha suas informações de assinatura do Azure à mão.

Clone o repositório GitHub do workbench:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Siga as instruções fornecidas no arquivo README.md.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Paolo Salvatori | Engenheiro principal de serviço

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Analise as recomendações e as práticas recomendadas para AKS no Microsoft Azure Well-Architected Framework:

Compartilhar via

Usar o Firewall do Azure para ajudar a proteger um cluster do AKS (Serviço de Kubernetes do Azure)