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

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

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

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

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 (VM) de jump-box e pontos de extremidade privados (VmSubnet).
Gateway de aplicativo WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

O cluster 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ê implante opcionalmente um cluster AKS que tenha estes recursos:

O cluster AKS é composto pelos seguintes pools:

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

Uma VM é implantada na rede virtual que hospeda o cluster AKS. Quando você implanta o AKS como um cluster privado, os administradores de sistema podem usar essa VM para gerenciar o cluster por meio da ferramenta de linha de comando Kubernetes. Os logs de diagnóstico de inicialização da VM são armazenados em uma conta de Armazenamento do Azure.

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

O AKS não fornece 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 aplicativo. 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 roteiam o tráfego de saída do cluster AKS para o Firewall do Azure.

Nota

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

Um Cofre de Chaves é usado como um armazenamento secreto por cargas de trabalho que são executadas no AKS para recuperar chaves, certificados e segredos por meio do ID de Carga de Trabalho do Microsoft Entra, do Driver CSI do Repositório de Segredos ou do Dapr. O Azure Private Link permite que cargas de trabalho AKS acessem serviços 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 espaço de trabalho do Log Analytics é usado para coletar os logs de diagnóstico e as métricas dos serviços do Azure.

Componentes

O Firewall do Azure é um serviço de segurança de firewall de rede inteligente nativo da nuvem que fornece proteção contra ameaças para cargas de trabalho de nuvem executadas no Azure. É uma firewall com total monitoração de estado como um serviço com elevada disponibilidade incorporada e escalabilidade da cloud sem restrições. Fornece inspeção de tráfego leste-oeste e norte-sul.
O Container Registry é um serviço de registro do Docker gerenciado e privado baseado no Docker Registry 2.0 de código aberto. Você pode usar registros de contêiner do Azure com seus pipelines de desenvolvimento e implantação de contêiner existentes ou usar Tarefas de Registro de Contêiner para criar imagens de contêiner no Azure.
O Serviço Kubernetes do Azure simplifica a implantação de clusters Kubernetes gerenciados no Azure descarregando a sobrecarga operacional para o Azure. Como um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade. Como os mestres do Kubernetes são gerenciados pelo Azure, você gerencia e mantém apenas os nós do agente.
O Cofre de Chaves armazena e controla o acesso a segredos como chaves de API, senhas, certificados e chaves criptográficas com segurança aprimorada. O Cofre da Chave também permite provisionar, gerenciar e implantar facilmente certificados públicos e privados de Transport Layer Security/Secure Sockets Layer (TLS/SSL), para uso com o Azure e seus recursos internos conectados.
O Azure Bastion é uma plataforma como serviço (PaaS) totalmente gerenciada que você provisiona dentro de sua rede virtual. O Azure Bastion fornece conectividade RDP (Remote Desktop Protocol) e SSH (Secure Shell) de segurança aprimorada para as VMs em sua rede virtual, diretamente do portal do Azure por 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 bloco de construção fundamental para as redes privadas do Azure. A Rede Virtual permite que os recursos do Azure (como VMs) se comuniquem entre si, com a Internet e com redes locais com segurança aprimorada. Uma rede virtual do Azure é como uma rede tradicional local, mas inclui benefícios da infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento.
As Interfaces de Rede Virtual permitem que as VMs do Azure se comuniquem com a Internet, o Azure e os recursos locais. Você pode adicionar várias placas de interface de rede a uma VM do Azure, para que as VMs filhas possam ter seus próprios dispositivos de interface de rede dedicados e endereços IP.
Os discos gerenciados do Azure fornecem volumes de armazenamento em nível de bloco que o Azure gerencia em VMs do Azure. Estão disponíveis discos Ultra, unidades de estado sólido (SSD) premium, SSD padrão e unidades de disco rígido (HDD) padrão.
O Blob Storage é uma solução de armazenamento de objetos para a nuvem. O armazenamento de Blob é otimizado para armazenar grandes quantidades de dados não estruturados.
O Private Link permite que você acesse os serviços PaaS do Azure (por exemplo, Armazenamento de Blobs e Cofre de Chaves) em um ponto de extremidade privado em 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 de cluster AKS precisam acessar portas específicas e FQDNs (nomes de domínio totalmente qualificados) associados a essas dependências de saída. Isso inclui acessar o servidor de API Kubernetes do seu próprio cluster, baixar e instalar componentes de cluster e extrair imagens de contêiner do Microsoft Container Registry. Essas dependências de saída são definidas com FQDNs e não possuem endereços estáticos, tornando impossível bloquear o tráfego de saída usando Grupos de Segurança de Rede. Portanto, os clusters AKS têm acesso irrestrito à Internet de saída (saída) por padrão para permitir que nós e serviços acessem recursos externos conforme necessário.

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

Uma solução simples é usar um dispositivo de firewall que possa controlar o tráfego de saída com base em 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 um controle de tráfego de saída refinado. Ele também permite a listagem de 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 de ameaças no Firewall do Azure implantada em uma rede de perímetro compartilhada pode controlar o tráfego de entrada e melhorar a segurança. Essa filtragem pode gerar alertas e negar tráfego de e para endereços IP e domínios mal-intencionados conhecidos.

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 Kubernetes do Azure (AKS). O cluster é hospedado por uma ou mais redes virtuais spoke emparelhadas à rede virtual do hub.

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

O Firewall Premium do Azure é recomendado para proteger 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 dimensionamento automático para lidar com períodos de pico de tráfego de até 30 Gbps. Ele suporta recursos corporativos, como inteligência de ameaças, proxy DNS, DNS personalizado e categorias da Web.
O Firewall do Azure Basic é recomendado para clientes com necessidades de taxa de transferência inferiores a 250 Mbps.

A tabela a seguir mostra os recursos das 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 AKS têm acesso irrestrito à Internet de saída. Esse nível de acesso à rede permite que nós e serviços executados no cluster AKS acessem recursos externos conforme necessário. Se você quiser restringir o tráfego de saída, um número limitado de portas e endereços deve permanecer acessível para manter as tarefas de manutenção do cluster íntegras. 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 FQDN (nome de domínio totalmente qualificado) do destino. Você também pode configurar seu firewall e regras de segurança para permitir essas portas e endereços necessários. Para obter mais informações, consulte 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 melhorar a segurança habilitando a filtragem baseada em inteligência de ameaças em um Firewall do Azure implantado em uma rede de perímetro compartilhada. Essa filtragem pode fornecer alertas e negar tráfego de e para endereços IP e domínios mal-intencionados conhecidos.

Potenciais casos de utilização

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

Evite 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 spoke. O Firewall do Azure usa coleções de regras de rede e aplicativos 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 ao endereço IP público do firewall, mas retornam ao firewall através do endereço IP privado (usando a rota padrão). Isto é 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. Os pacotes que vão para o endereço IP público do firewall são roteados através da Internet. Essa configuração evita a rota padrão para o endereço IP privado do firewall.

Para rotear o tráfego de suas cargas de trabalho do AKS para o Firewall do Azure na rede virtual do 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 salto seguinte.

Para obter mais informações, consulte Tutorial: Implantar e configurar o Firewall do Azure usando o portal do Azure.

Para obter mais informações, consulte:

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

Se você usa o Azure DevOps, observe que não pode 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. Neste ú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, consulte Agentes do Conjunto de Dimensionamento de Máquina Virtual 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 obter mais informações, consulte:

Se as sub-redes que hospedam os pools de nós do seu 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 uma rota definida pelo usuário, certifique-se de criar 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, CLI do Azure 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) na rede virtual que hospeda seu cluster AKS ou em uma rede virtual emparelhada. Os Pools de DevOps Gerenciados capacitam as equipes de desenvolvimento a criar pools de agentes do Azure DevOps adaptados às suas necessidades específicas. Ele implementa 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 de pools de DevOps gerenciados da Microsoft.

Você pode adicionar agentes de um Pool de DevOps Gerenciado em sua rede virtual, permitindo que os pipelines de CI/CD interajam com o servidor de API do Kubernetes do seu cluster AKS privado e acessem recursos do Azure, como o Registro de Contêiner do Azure, que têm o acesso à rede pública desabilitado 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 Configurar redes de pools de DevOps gerenciados.

Usar o Firewall do Azure na frente de um Balanceador de Carga Padrão público

As definições de recursos nos módulos Terraform usam o meta-argumento lifecycle 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 para 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 as regras de DNAT, aplicativo e 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 do Azure DevOps que mostra como implantar uma carga de trabalho em um cluster AKS privado usando um pipeline do Azure DevOps executado em um agente auto-hospedado. 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:

Aqui está o fluxo de mensagens:

Uma solicitação para o aplicativo Web hospedado pelo AKS é enviada para um IP público exposto pelo Firewall do Azure por meio de uma configuração de IP pública. 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 Balanceador de Carga 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 do agente do cluster AKS.
A mensagem de resposta é enviada de volta ao chamador original através 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 salto seguinte.
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 do endereço e Virtual appliance é o tipo Next hop.

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

Usar o Firewall do Azure na frente de um Balanceador de Carga Padrão interno

No exemplo associado a este artigo, um aplicativo ASP.NET Core é hospedado como um serviço por um cluster AKS e encabeçado por um controlador de entrada NGINX. O controlador de entrada NGINX é exposto através 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 LoadBalancer ou ClusterIP serviço, com a service.beta.kubernetes.io/azure-load-balancer-internal: "true" anotação na seção de metadados, um balanceador de carga padrão interno chamado kubernetes-internal é criado sob o grupo de recursos do nó. Para obter mais informações, consulte Usar um balanceador de carga 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.

Aqui está o fluxo de mensagens:

Uma solicitação para o aplicativo Web de teste hospedado pelo AKS é enviada para um IP público exposto pelo Firewall do Azure por meio de uma configuração de IP pública. 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 privado e a porta usados pelo controlador de entrada NGINX no Balanceador de Carga 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 do agente do cluster AKS.
A mensagem de resposta é enviada de volta ao chamador original através de uma rota definida pelo usuário. 0.0.0.0/0 é o prefixo do endereço e Virtual appliance é o tipo Next hop.
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 Balanceador de Carga Padrão interno.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar 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 às considerações de segurança, desempenho, disponibilidade e confiabilidade, armazenamento, malha de serviço e monitoramento.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

A plataforma Azure fornece proteção aprimorada contra várias ameaças, como intrusão de rede e ataques distribuídos de negação de serviço (DDoS). Você deve usar um firewall de aplicativo da Web (WAF) para fornecer proteção para quaisquer aplicativos e serviços da Web hospedados pelo 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 aprimorada de seus aplicativos Web contra explorações e vulnerabilidades comuns. Você pode implantar o Azure WAF com o Azure Application Gateway, 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 DDoS tenta esgotar os recursos de um aplicativo, tornando o aplicativo indisponível para usuários legítimos. Os ataques DDoS podem ser direcionados a qualquer ponto final que seja publicamente acessível através da Internet. Todas as propriedades no Azure incluem proteção por meio da proteção de infraestrutura DDoS do Azure sem custo extra. A escala e a capacidade da rede do Azure implantada globalmente fornecem defesa aprimorada contra ataques comuns da camada de rede por meio de monitoramento de tráfego sempre ativo e mitigação em tempo real. A proteção da infraestrutura DDoS não requer nenhuma configuração do usuário ou alterações no aplicativo. Ajuda a proteger todos os serviços do Azure, incluindo serviços PaaS como o DNS do Azure.

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

Seguem-se algumas considerações adicionais de segurança:

Crie um ponto de extremidade privado para qualquer serviço PaaS usado por cargas de trabalho do AKS, como o Cofre de Chaves, o Barramento de Serviço do Azure e o Banco de Dados SQL do Azure. O tráfego entre as aplicações e estes serviços não está exposto à Internet pública. O tráfego entre a rede virtual do cluster AKS e uma instância de um serviço PaaS através de um ponto de extremidade privado percorre a rede de backbone da Microsoft, mas a comunicação não passa pelo Firewall do Azure. Este mecanismo proporciona uma melhor segurança e uma melhor proteção contra fugas de dados. Para obter mais informações, consulte O que é o Azure Private Link?.
Ao usar o Application Gateway 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 segregar e ajudar a proteger as comunicações intrasserviço, controlando quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster Kubernetes podem enviar e receber tráfego sem limitações. Para melhorar a segurança, você pode usar as políticas de rede do Azure ou as políticas de rede do Calico para definir regras que controlam o fluxo de tráfego entre diferentes microsserviços. Para obter mais informações, consulte Diretiva de rede.
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 o tráfego para seu cluster AKS.
Considere o uso de um cluster AKS privado em seu ambiente de produção, ou pelo menos o acesso seguro ao servidor 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 em 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 é crucial e necessária para uma filtragem FQDN confiável em regras de rede. Você pode habilitar o proxy DNS nas configurações de Firewall e Política de 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 certificado digital separados para cada locatário. O Application Gateway Ingress Controller (AGIC) configura automaticamente o ouvinte do Application Gateway para terminação SSL (Secure Sockets Layer).
Você pode usar o Firewall do Azure na frente de um proxy de serviço, como o controlador de entrada NGINX. Este controlador fornece proxy reverso, roteamento de tráfego configurável e terminação TLS para serviços Kubernetes. Os recursos de entrada do Kubernetes são utilizados para configurar regras e rotas de entrada para serviços individuais do Kubernetes. Usando 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 Kubernetes. Você pode gerar os certificados TLS usando uma autoridade de certificação reconhecida. Como alternativa, você pode usar 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 obter mais informações, consulte Criar um controlador de entrada HTTPS e usar seus próprios certificados TLS no AKS.
A coordenação rigorosa 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 as necessidades de carga de trabalho e 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 fiabilidade

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

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

Resiliência intrarregião

Durante a implantação, você pode configurar o Firewall do Azure para abranger várias zonas de disponibilidade para aumentar a 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 de zona de interdisponibilidade.
Considere implantar os pools de nós do cluster AKS em todas as zonas de disponibilidade de uma região. Use um Balanceador de Carga Padrão do Azure ou um Gateway de Aplicativo na frente dos pools de nós. Essa topologia fornece melhor resiliência se houver uma única interrupção do datacenter. Os nós de cluster são distribuídos em vários datacenters, em três zonas de disponibilidade separadas dentro de uma região.
Habilite a redundância de zona no Registro de Contêiner para resiliência intrarregião e alta disponibilidade.
Use restrições de propagação de topologia de pod para controlar como os pods são distribuídos pelo cluster AKS entre domínios de falha, como regiões, zonas de disponibilidade e nós.
Considere o uso do SLA de tempo de atividade para clusters AKS que hospedam cargas de trabalho de missão crítica. O SLA de tempo de atividade é um recurso opcional que permite um SLA mais alto e com suporte financeiro para um cluster. O SLA de tempo de atividade garante alta disponibilidade do ponto de extremidade do servidor da 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 Uptime SLA. O AKS utiliza réplicas de nó principal em domínios de atualização e de falha para garantir que os requisitos de SLA são respeitados.

Recuperação após desastre e continuidade de negócio

Considere implantar sua solução em pelo menos duas regiões emparelhadas do Azure dentro de uma geografia. Use um balanceador de carga global, como o Azure Traffic Manager ou o Azure Front Door, com um método de roteamento ativo/ativo ou ativo/passivo, para garantir a continuidade de negócios e a recuperação de desastres (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 são sempre priorizadas acima das coleções de regras de rede definidas como parte de uma 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 das coleções de regras de aplicativo, independentemente da herança. Para obter mais informações sobre as 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 DR atende às metas de RPO/RTO, em conjunto com eventuais processos manuais e intervenções necessárias 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. Replique geograficamente o registo para cada região AKS. Para obter mais informações, consulte 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, use um PaaS do Azure que ofereça suporte à replicação de várias regiões.
Se você usar o Armazenamento do Azure, prepare e teste um processo para migrar seu armazenamento da região primária para a região de backup.

Excelência operacional

A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte 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 o GitHub Actions ou o Azure DevOps. Para obter mais informações, consulte Criar e implantar no Serviço Kubernetes do Azure.
Para testar corretamente um aplicativo antes de disponibilizá-lo aos usuários, use testes A/B e implantações canárias no gerenciamento do ciclo de vida do aplicativo. Há várias técnicas que você pode usar para dividir o tráfego em diferentes versões do mesmo serviço. Como alternativa, você pode usar os recursos de divisão de tráfego fornecidos 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 Hub do Docker) para armazenar as imagens privadas do Docker implantadas no cluster. O AKS pode autenticar-se com o Registo de Contentores do Azure utilizando a sua identidade Microsoft Entra.
Teste a entrada e saída de suas cargas de trabalho em um ambiente de pré-produção separado que espelha a topologia de rede e as regras de firewall do seu ambiente de produção. Uma estratégia de distribuição em estágios ajudará você a detetar quaisquer problemas de rede ou segurança antes de lançar um novo recurso ou regra de rede em produção.

Monitorização

O Firewall do Azure é totalmente integrado ao Azure Monitor para registrar o tráfego de entrada e saída processado pelo firewall. Para obter mais informações, consulte Filtragem baseada em inteligência de 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 esta solução.

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

Otimização de custos

O custo da arquitetura resultante depende dos seguintes detalhes de configuração:

Escalões de serviço
Escalabilidade (o número de instâncias que são alocadas dinamicamente pelos serviços para dar suporte a uma determinada demanda)
Scripts de automatização
Seu nível de recuperação de desastres

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, consulte os princípios de otimização de custos no Microsoft Azure Well-Architected Framework.

Implementar este cenário

O código-fonte para este cenário está disponível no GitHub. Esta 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. Se você não tiver uma, crie uma conta gratuita do Azure 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 remoto do Terraform, o bloqueio de estado e a criptografia em repouso, consulte Armazenar o estado do 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 receba a função de proprietário em toda a assinatura.

Implantação no Azure

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

Clone o repositório GitHub da bancada de trabalho:

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

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Paolo Salvatori - Brasil | Engenheiro de Serviços Principal

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

Próximos passos

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

Partilhar via

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