Esta solução usa o Azure Web Application Firewall (WAF) para ajudar a fornecer proteção centralizada para aplicativos Web que você implanta em um cluster multilocatário do Serviço Kubernetes do Azure (AKS). O WAF ajuda a proteger contra exploits e vulnerabilidades comuns.
Você pode usar uma política WAF no Gateway de Aplicativo do Azure para ajudar a proteger aplicativos Web contra ataques mal-intencionados, como injeção de SQL e scripts entre sites. Esse método ajuda a proteger aplicativos da Web que são executados em um cluster AKS e são expostos por meio do Application Gateway Ingress Controller (AGIC). A política WAF no Application Gateway é pré-configurada com o Open Worldwide Application Security Project (OWASP) Core Rule set (CRS) e suporta outras versões do OWASP CRS. Você também pode criar regras personalizadas.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
Essa arquitetura usa um modelo complementar do Azure Resource Manager (modelo ARM) para implantar uma nova rede virtual que tem quatro sub-redes:
- AksSubnet hospeda o cluster AKS.
- VmSubnet hospeda uma máquina virtual (VM) jumpbox e pontos de extremidade privados.
- AppGatewaySubnet hospeda a camada WAF2 do Application Gateway.
- AzureBastionSubnet hospeda o Azure Bastion.
O cluster AKS usa uma identidade gerenciada definida pelo usuário para criar mais recursos, como balanceadores de carga e discos gerenciados, no Azure. Você pode usar o modelo ARM para implantar um cluster AKS que tenha os seguintes recursos:
- Drivers CSI (Container Storage Interface) para discos do Azure e Arquivos do Azure
- Integração do Microsoft Entra gerenciada pelo AKS
- RBAC (controle de acesso baseado em função) do Azure para Autorização do Kubernetes
- Uma identidade gerenciada no lugar de uma entidade de serviço
- ID da carga de trabalho do Microsoft Entra
- Políticas de rede do Azure
- Complemento Azure Monitor Container Insights
- Complemento AGIC
- Alocação dinâmica de endereços IP e suporte aprimorado a sub-redes
O cluster AKS tem os seguintes pools de nós:
- O pool de nós do sistema hospeda apenas pods e serviços críticos do sistema. Os nós de trabalho têm coloração de nó que impede que pods de aplicativo sejam agendados nesse pool de nós.
- O pool de nós do usuário hospeda cargas de trabalho e artefatos do usuário.
Uma VM é implantada na mesma 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 Secure Shell (SSH) segura e contínua para a VM jumpbox, diretamente no portal do Azure por meio do SSL (Secure Sockets Layer). Essa solução usa o Registro de Contêiner do Azure para criar, armazenar e gerenciar imagens de contêiner e artefatos, como gráficos Helm.
A arquitetura inclui um gateway de aplicativo que o controlador de entrada usa. O gateway de aplicativo é implantado em uma sub-rede dedicada e exposto à Internet pública por meio de um endereço IP público que todas as cargas de trabalho do locatário compartilham. Uma política WAF ajuda a proteger as cargas de trabalho do locatário contra ataques mal-intencionados.
A política WAF está associada ao gateway de aplicativo no nível raiz e no nível de ouvinte HTTP. A política é configurada no modo de prevenção e usa o OWASP 3.1 para bloquear invasões e ataques detetados pelas regras. O invasor recebe uma exceção de acesso não autorizado 403 e a conexão é fechada. O modo de prevenção registra esses ataques nos logs do WAF.
As cargas de trabalho executadas no AKS usam um cofre de chaves como um armazenamento secreto para recuperar chaves, certificados e segredos por meio de uma biblioteca de cliente, Driver CSI do Repositório de Segredos ou Dapr. O Azure Private Link permite que cargas de trabalho AKS acessem soluções de plataforma como serviço (PaaS) do Azure, como o Azure Key Vault, em um ponto de extremidade privado na rede virtual.
Essa arquitetura inclui pontos de extremidade privados para os seguintes componentes:
- A conta de Armazenamento de Blob do Azure
- Container Registry
- Key Vault
- O servidor de API do cluster Kubernetes, se você usar um cluster AKS privado
A arquitetura também inclui zonas DNS privadas para resolver o nome de domínio totalmente qualificado (FQDN) de um serviço PaaS para o endereço IP privado de seu ponto de extremidade privado associado. Essa arquitetura inclui zonas DNS privadas para resolver os pontos de extremidade privados para os seguintes componentes:
- A conta de armazenamento de Blob
- Container Registry
- Key Vault
- A API do Kubernetes Server, se você implantar o cluster como privado
Existe um link de rede virtual entre a rede virtual que hospeda o cluster AKS e as zonas DNS privadas anteriores. Um espaço de trabalho do Log Analytics coleta os logs e métricas de diagnóstico das seguintes fontes:
- O cluster AKS
- A VM jumpbox
- Gateway de Aplicação
- Key Vault
- Grupos de segurança de rede do Azure
Componentes
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 use tarefas do Registro de Contêiner para criar imagens de contêiner no Azure. Você pode criar sob demanda ou automatizar totalmente as compilações com gatilhos, como confirmações de código-fonte e atualizações de imagem base.
O AKS simplifica a implantação de um cluster Kubernetes gerenciado 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. O Azure gerencia nós de plano de controle do Kubernetes, para que você gerencie e mantenha apenas os nós do agente.
O Cofre de Chaves ajuda a armazenar e controlar com segurança o acesso a segredos, como chaves de API, senhas, certificados e chaves criptográficas. Você pode usar o Cofre da Chave para provisionar, gerenciar e implantar facilmente certificados TLS (Transport Layer Security) ou SSL públicos e privados e usá-los com o Azure e seus recursos internos conectados.
O Application Gateway é um balanceador de carga de tráfego da Web que você pode usar para gerenciar o tráfego de entrada que vai para aplicativos Web downstream e APIs REST. Os balanceadores de carga tradicionais operam na camada de transporte, que é a camada 4 de Interconexão de Sistemas Abertos (OSI), para lidar com o tráfego que usa TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Eles roteiam o tráfego com base no endereço IP de origem e na porta para um endereço IP e uma porta de destino. Um gateway de aplicativo é um balanceador de carga na camada de aplicativo, que é a camada OSI 7.
O WAF é um serviço que ajuda a fornecer proteção centralizada de aplicativos da Web contra exploits e vulnerabilidades comuns. O WAF baseia-se nas regras do OWASP CRS. Você pode usar o WAF para criar regras personalizadas que são avaliadas para cada solicitação que passa por uma política. Essas regras têm uma prioridade maior do que o resto das regras nos conjuntos de regras gerenciados. As regras personalizadas contêm um nome de regra, prioridade de regra e uma matriz de condições correspondentes. Se a solicitação atender a essas condições, o WAF permitirá ou bloqueará a solicitação com base na regra.
O Azure Bastion é um PaaS totalmente gerenciado que você provisiona dentro de sua rede virtual. O Azure Bastion ajuda a fornecer conectividade segura e contínua de Protocolo de Área de Trabalho Remota (RDP) e SSH 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 e sob demanda que oferecem a flexibilidade da virtualização sem a necessidade de comprar e manter o hardware físico.
A Rede Virtual do Azure é o bloco de construção fundamental para as redes privadas do Azure. Com a Rede Virtual, os recursos do Azure, como VMs, podem se comunicar entre si, com a Internet e com as redes locais de maneira mais segura. Uma rede virtual do Azure é semelhante a uma rede tradicional local, mas inclui benefícios de infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento.
As interfaces de rede virtual ajudam a estabelecer a comunicação entre as VMs do Azure e 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 são volumes de armazenamento em nível de bloco que o Azure gerencia em VMs do Azure. Os tipos de disco incluem o Azure Ultra Disk Storage, o Azure Premium SSD, o Azure Standard SSD e o Azure Standard HDD.
O Blob Storage é uma solução de armazenamento de objetos da Microsoft para a nuvem. O armazenamento de Blob é otimizado para armazenar grandes quantidades de dados não estruturados. Dados não estruturados são dados que não aderem a um modelo ou definição de dados específico, como dados de texto ou dados binários.
O Private Link fornece um ponto de extremidade privado em sua rede virtual para que você possa acessar os serviços PaaS do Azure, como o Armazenamento de Blobs e o Cofre de Chaves, e acessar serviços hospedados pelo Azure, de propriedade do cliente ou serviços de parceiros.
Alternativas
Quando você expõe cargas de trabalho que hospeda em um cluster AKS, você tem várias soluções a considerar. Em vez de usar o AGIC, você pode usar o Application Gateway for Containers ou a entrada NGINX gerenciada com o complemento de roteamento de aplicativo. Essas alternativas fornecem diferentes recursos para ajudar a gerenciar e proteger o tráfego para seu cluster AKS.
Esta arquitetura instala o AGIC através do add-on AGIC para AKS. Você também pode instalar o AGIC através de um gráfico Helm. Ao criar uma nova configuração, você pode usar uma linha na CLI do Azure para implantar um novo gateway de aplicativo e um novo cluster AKS. Este método habilita o AGIC como um complemento. O complemento é um serviço totalmente gerenciado, que oferece benefícios adicionais, como atualizações automáticas e maior suporte. Também é considerado um complemento de primeira classe, que oferece melhor integração com o AKS. A Microsoft suporta ambos os métodos de implantação para o AGIC.
O complemento AGIC é implantado como um pod em seu cluster AKS. Mas há algumas diferenças entre a versão de implantação do Helm e a versão complementar do AGIC. A lista a seguir inclui as diferenças entre as duas versões:
Não é possível modificar os valores de implantação do Helm no complemento AKS:
- A
usePrivateIp
propriedade é definida comofalse
por padrão. Não é possível substituir esse valor por meio dause-private-ip
anotação. - O complemento não suporta a
shared
opção de configuração.
- A
O AGIC implantado pelo Helm suporta
ProhibitedTargets
, o que significa que o AGIC pode configurar o gateway de aplicativo especificamente para clusters AKS sem afetar outros back-ends existentes.O complemento AGIC é um serviço gerenciado, portanto, atualiza automaticamente para a versão mais recente. Se você implantar o AGIC via Helm, deverá atualizar manualmente o AGIC.
Você só pode implantar um complemento AGIC para cada cluster AKS. Cada complemento AGIC só pode ter como alvo uma instância do Application Gateway. Para implantações que exigem mais de um AGIC para cada cluster ou vários AGICs destinados a uma instância do Application Gateway, você pode usar o AGIC implantado em leme.
Uma única instância do AGIC pode ingerir eventos de vários namespaces do Kubernetes. Se o administrador do AKS usar o gateway de aplicativo como uma entrada, todos os namespaces usarão a mesma instância do Application Gateway. Uma única instalação do AGIC monitora namespaces acessíveis e configura o gateway de aplicativo ao qual está associado. Para obter mais informações, consulte Habilitar suporte a vários namespaces em um cluster AKS com o AGIC.
Para habilitar o suporte a vários namespaces, execute as seguintes etapas:
- Modifique o arquivo helm-config.yaml de uma das seguintes maneiras:
- Exclua a
watchNamespace
chave inteiramente do arquivo helm-config.yaml para permitir que o AGIC observe todos os namespaces. - Defina
watchNamespace
como uma cadeia de caracteres vazia para permitir que o AGIC observe todos os namespaces. - Adicione vários namespaces separados por uma vírgula, como
watchNamespace: default,secondNamespace
, para permitir que o AGIC observe esses namespaces exclusivamente.
- Aplique as alterações do modelo Helm com este script:
helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure
.
Depois de implantar o AGIC com a capacidade de observar vários namespaces, o AGIC executa as seguintes ações:
- Lista recursos de entrada de todos os namespaces acessíveis
- Filtra recursos de entrada que são anotados com
kubernetes.io/ingress.class: azure/application-gateway
- Compõe a configuração combinada do Application Gateway
- Aplica a configuração ao gateway de aplicativo associado por meio do Azure Resource Manager
Detalhes do cenário
Essa arquitetura compartilha um cluster Kubernetes multilocatário entre vários usuários e cargas de trabalho que são comumente chamados de locatários. Essa definição inclui diferentes equipes ou divisões dentro de uma organização que compartilham clusters do Kubernetes. Ele também inclui clusters que são compartilhados por instâncias por cliente de um aplicativo SaaS (software como serviço). A multilocação de cluster é uma alternativa ao gerenciamento de muitos clusters dedicados de locatário único. Os operadores de um cluster Kubernetes multilocatário devem isolar os locatários uns dos outros. Esse isolamento minimiza os danos que um locatário comprometido ou mal-intencionado pode causar ao cluster e a outros locatários. Quando vários usuários ou equipes compartilham o mesmo cluster que tem um número fixo de nós, uma equipe pode usar mais recursos do que precisam. Os administradores podem usar cotas de recursos para resolver essa preocupação.
Ao planejar criar um cluster AKS multilocatário, você deve considerar as camadas de isolamento de recursos que o Kubernetes fornece, incluindo cluster, namespace, nó, pod e isolamento de contêiner. Você também deve considerar as implicações de segurança do compartilhamento de diferentes tipos de recursos entre vários locatários. Por exemplo, se você agendar pods de locatários diferentes no mesmo nó, poderá reduzir o número de máquinas necessárias no cluster. Por outro lado, talvez seja necessário impedir que determinadas cargas de trabalho sejam colocalizadas. Por exemplo, você pode não permitir que códigos não confiáveis de fora da sua organização sejam executados no mesmo nó que os contêineres que processam informações confidenciais. Você pode usar a Política do Azure para que apenas registros confiáveis possam implantar no AKS.
O Kubernetes não pode garantir um isolamento perfeitamente seguro entre locatários, mas oferece recursos que fornecem segurança suficiente para casos de uso específicos. Como prática recomendada, você deve separar cada locatário e seus recursos do Kubernetes em seus próprios namespaces. Em seguida, você pode usar o RBAC do Kubernetes e as políticas de rede para ajudar a impor o isolamento do locatário. Por exemplo, o diagrama a seguir mostra um modelo de provedor SaaS típico que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo está em um namespace separado. Quando os locatários precisam de um nível mais alto de isolamento físico e desempenho garantido, suas cargas de trabalho podem ser implantadas em um conjunto dedicado de nós, um pool dedicado ou até mesmo um cluster dedicado.
O AGIC é um aplicativo Kubernetes, portanto , os clientes AKS podem usar um gateway de aplicativo para expor seus aplicativos em contêineres à Internet. O AGIC monitora o cluster Kubernetes no qual está hospedado e atualiza continuamente um gateway de aplicativo para que os serviços selecionados sejam expostos à Internet. O AGIC é executado em seu próprio pod na instância AKS do cliente. O AGIC monitora um subconjunto de recursos do Kubernetes em busca de alterações. O estado do cluster AKS é traduzido para a configuração específica do Application Gateway e aplicado ao Resource Manager. Essa arquitetura descreve práticas comprovadas para implantar um cluster AKS público ou privado por meio de um gateway de aplicativo e um complemento AGIC.
Uma única instância do AGIC pode ingerir eventos e observar vários namespaces. Se o administrador do AKS usar o Application Gateway como uma entrada, todos os namespaces usarão a mesma instância do Application Gateway. Uma única instalação do AGIC monitora namespaces acessíveis e configura o gateway de aplicativo ao qual ele está associado.
Potenciais casos de utilização
Use o AGIC para expor e proteger cargas de trabalho voltadas para a Internet que são executadas em um cluster AKS em um ambiente multilocatário.
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 dessas considerações não dizem respeito totalmente à multilocação no AKS, mas são requisitos essenciais desta solução. Essas considerações incluem segurança, desempenho, disponibilidade, confiabilidade, armazenamento, agendador, malha de serviço e orientação de monitoramento.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.
Essas considerações de disponibilidade e confiabilidade não dizem respeito totalmente à multilocação no AKS, mas são requisitos essenciais desta solução. Considere as seguintes maneiras de otimizar a disponibilidade para seu cluster e cargas de trabalho AKS.
Contentores
Use as sondas de integridade do Kubernetes para verificar se seus contêineres estão vivos e saudáveis:
O livenessProbe indica se o contêiner está em execução. Se o teste de vivacidade falhar, o kubelet encerrará o contêiner e o contêiner será submetido à sua política de reinicialização.
O proincisProbe indica se o contêiner está pronto para responder às solicitações. Se a sonda de prontidão falhar, o controlador de ponto de extremidade removerá o endereço IP do pod dos pontos de extremidade de todos os serviços que correspondem ao pod. O estado padrão de prontidão antes do atraso inicial é a falha.
O startupProbe indica se o aplicativo dentro do contêiner foi iniciado. Se você tiver um teste de inicialização, todos os outros testes serão desativados até que o teste de inicialização seja bem-sucedido. Se o teste de inicialização falhar, o kubelet encerrará o contêiner e o contêiner será submetido à sua política de reinicialização.
A contenção de recursos pode afetar a disponibilidade do serviço. Defina restrições de recursos de contêiner para que nenhum contêiner possa sobrecarregar a memória do cluster e os recursos da CPU. Você pode usar o diagnóstico do AKS para identificar quaisquer problemas no cluster.
Use o limite de recursos para restringir o total de recursos alocados a um contêiner para que um contêiner não possa privar outros.
Container Registry
Armazene imagens de contêiner no Registro de contêiner. Use a replicação geográfica do Registro de Contêiner para replicar geograficamente o registro para cada região do AKS. A replicação geográfica é um recurso do Premium SKU Container Registry.
Analise suas imagens de contêiner em busca de vulnerabilidades. Implante apenas imagens que passam na validação. Atualize regularmente as imagens base e o tempo de execução do aplicativo e, em seguida, reimplante suas cargas de trabalho no cluster AKS.
Limite os registros de imagem que pods e implantações podem usar. Restrinja o acesso a registos fidedignos onde pode validar e controlar as imagens disponíveis.
Analise imagens de contêiner em busca de vulnerabilidades como parte de um pipeline de integração contínua e entrega contínua (CI/CD) antes de publicar imagens no Registro de contêiner. Ao usar imagens de base para imagens de aplicativos, use a automação para criar novas imagens ao atualizar a imagem base. As imagens base geralmente incluem correções de segurança, portanto, você deve atualizar todas as imagens de contêiner de aplicativo downstream. Recomendamos que você integre o Azure Defender for Containers em fluxos de trabalho de CI/CD. Para obter mais informações, consulte Automatizar compilações de imagens de contêiner.
Use as tarefas do Registro de contêiner para automatizar a aplicação de patches de sistema operacional e estrutura para seus contêineres do Docker. As tarefas do Registro de contêiner oferecem suporte a um processo de compilação automatizado quando você atualiza a imagem base de um contêiner. Por exemplo, você pode corrigir o sistema operacional ou a estrutura do aplicativo em uma de suas imagens base.
Resiliência intrarregião
Considere implantar os pools de nós do cluster AKS em todas as zonas de disponibilidade dentro de uma região. Use o Balanceador de Carga Padrão do Azure ou o Gateway de Aplicativo na frente dos pools de nós. Essa topologia fornece melhor resiliência se ocorrer uma única interrupção do datacenter. Esse método distribui nós de cluster em vários datacenters que residem 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 você espalha pods pelo cluster AKS entre domínios de falha, como regiões, zonas de disponibilidade e nós.
Considere o uso de um contrato de nível de serviço (SLA) de tempo de atividade para clusters AKS que hospedam cargas de trabalho de missão crítica. Um SLA de tempo de atividade é um recurso opcional para habilitar um SLA mais alto com suporte financeiro para um cluster. Um SLA de tempo de atividade garante 99,95% de disponibilidade do ponto de extremidade do servidor da API do Kubernetes para clusters que usam zonas de disponibilidade. Ele garante 99,90% de disponibilidade para clusters que não usam zonas de disponibilidade. O AKS usa réplicas de nó de plano de controle em domínios de atualização e falha para ajudar a atender aos requisitos de SLA.
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. Você também deve adotar um balanceador de carga global, como o Azure Traffic Manager ou o Azure Front Door. Combine o balanceador de carga com um método de roteamento ativo/ativo ou ativo/passivo para ajudar a garantir a continuidade dos negócios e a recuperação de desastres.
Crie, documente e teste periodicamente quaisquer processos de failover regionais em um ambiente de garantia de qualidade. Os processos de failover ajudam a evitar problemas imprevisíveis se uma interrupção na região principal afetar um serviço principal.
Use testes de processo de failover para verificar se a abordagem de recuperação de desastres atende às metas RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e RTO (Recovery Time Objetive, objetivo de tempo de recuperação). Inclua processos manuais e intervenções na sua verificação.
Teste os procedimentos de failback para garantir que eles funcionem 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.
Evite armazenar o estado de serviço dentro de um contêiner, sempre que possível. Em vez disso, use um PaaS do Azure que ofereça suporte à replicação de várias regiões.
Prepare e teste como migrar seu armazenamento da região primária para a região de backup se você usar o Armazenamento do Azure.
Considere usar o GitOps para implantar a configuração do cluster. O GitOps fornece uniformidade entre os clusters primário e de recuperação de desastres e também fornece uma maneira rápida de reconstruir um novo cluster se você perder um.
Considere o backup e a restauração da configuração do cluster usando ferramentas, como AKS backup ou Velero.
Malha de serviço
Considere usar uma malha de serviço de código aberto, como Istio, Linkerd ou Consul, em seu cluster AKS. Uma malha de serviço usa TLS mútuo para ajudar a melhorar a observabilidade, a confiabilidade e a segurança de seus microsserviços. Você também pode implementar estratégias de divisão de tráfego, como implantações azuis/verdes e implantações canárias. Uma malha de serviço é uma camada de infraestrutura dedicada que ajuda a tornar a comunicação serviço-a-serviço mais segura, rápida e confiável. Para obter mais informações, consulte Istio service mesh AKS add-on.
Considere a adoção do Dapr para criar aplicativos resilientes baseados em microsserviços, sejam eles sem estado e com monitoração de estado. Você pode usar qualquer linguagem de programação e estrutura de desenvolvedor.
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 Lista de verificação de revisão de design para segurança.
As considerações de segurança não dizem totalmente respeito à multilocação no AKS, mas são requisitos essenciais desta solução.
Multilocação
Projete clusters AKS para multilocação. O Kubernetes fornece recursos que você pode usar para isolar logicamente equipes e cargas de trabalho no mesmo cluster. Forneça o menor número de privilégios aos recursos de que cada equipe precisa. Um namespace no Kubernetes cria um limite de isolamento lógico.
Use o isolamento lógico para separar equipes e projetos. Minimize o número de clusters físicos AKS que você implanta para isolar equipes ou aplicativos. A separação lógica de clusters geralmente fornece uma densidade de pod maior do que clusters fisicamente isolados.
Use pools de nós dedicados ou clusters AKS dedicados sempre que precisar implementar um isolamento físico rigoroso. Por exemplo, você pode dedicar um pool de nós de trabalho ou um cluster inteiro a uma equipe ou locatário em um ambiente multilocatário.
Use uma combinação de manchas e tolerâncias para controlar a implantação de pods em um pool de nós específico. Você só pode manchar um nó no AKS no momento da criação do pool de nós. Como alternativa, você pode usar rótulos e seletores de nodePool para implantar a carga de trabalho somente em pools de nós específicos.
Segurança da rede
Crie um ponto de extremidade privado para qualquer serviço PaaS que suas cargas de trabalho AKS usem, como o Cofre da Chave, o Barramento de Serviço do Azure ou o Banco de Dados SQL do Azure. Um ponto de extremidade privado ajuda a garantir que o tráfego entre os aplicativos e esses serviços não seja exposto à Internet pública. Para obter mais informações, consulte O que é Private Link.
Configure seu recurso de ingresso do Kubernetes para expor cargas de trabalho via HTTPS. Use um subdomínio e um certificado digital separados para cada locatário. O AGIC configura automaticamente o ouvinte do Application Gateway para terminação SSL.
Configure o Application Gateway para usar uma política WAF para ajudar a proteger cargas de trabalho voltadas para o público que são executadas no AKS contra ataques mal-intencionados.
Use a rede CNI do Azure no AKS para integrar com redes virtuais existentes ou redes locais. Este modelo de rede também permite uma maior separação de recursos e controles em um ambiente corporativo.
Use políticas de rede para segregar e proteger as comunicações dentro do serviç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 vários 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 jumpbox, em uma rede virtual de gerenciamento. Use o host bastion para rotear com segurança o tráfego para seu cluster AKS para tarefas de gerenciamento remoto.
Considere o uso de intervalos de endereços IP autorizados no AKS para criar um cluster AKS privado em seu ambiente de produção. Se você não puder usar um cluster AKS privado, pelo menos proteja o acesso ao servidor de API.
Combine a Proteção contra DDoS do Azure com as práticas recomendadas de design de aplicativos para fornecer recursos aprimorados de mitigação de DDoS e defesa extra contra ataques DDoS. Habilite a Proteção contra DDoS em redes virtuais de perímetro.
Autenticação e autorização
Implante clusters AKS com a integração do Microsoft Entra. Para obter mais informações, consulte Integração do Microsoft Entra gerenciada pelo AKS. O Microsoft Entra ID centraliza o componente de gerenciamento de identidade.
Use o RBAC do Kubernetes para definir as permissões que os usuários ou grupos têm para recursos no cluster. Use funções ou ClusterRoles e associações para definir o escopo de usuários ou grupos para o menor número de permissões necessárias. Integre o Kubernetes RBAC com o Microsoft Entra ID para que qualquer alteração no status do usuário ou na associação ao grupo atualize automaticamente o acesso aos recursos do cluster. Para obter mais informações, consulte Kubernetes RBAC.
Use o RBAC do Azure para definir as permissões mínimas necessárias que os usuários ou grupos têm para recursos AKS em uma ou mais assinaturas. Para obter mais informações, consulte Usar o RBAC do Azure para autorização do Kubernetes.
Use a ID de Carga de Trabalho do Microsoft Entra para atribuir uma identidade gerenciada a microsserviços individuais para acesso a recursos do Azure. O microsserviço pode acessar recursos gerenciados, como Cofre de Chaves, Banco de Dados SQL, Service Bus e Azure Cosmos DB. O microsserviço não precisa armazenar e recuperar cadeias de conexão ou credenciais de segredos do Kubernetes.
Use o Driver CSI do Secrets Store for Key Vault para acessar segredos, como credenciais e cadeia de conexões, do Key Vault em vez de segredos do Kubernetes.
Combine o bloco de construção do armazenamento secreto Dapr com o armazenamento do Cofre de Chaves e identidades gerenciadas no Kubernetes para recuperar segredos, como credenciais e cadeias de conexão, do Cofre da Chave.
Carga de trabalho e cluster
Proteja o acesso ao servidor de API do Kubernetes para ajudar a proteger seu cluster. Integre o Kubernetes RBAC com o Microsoft Entra ID para controlar o acesso ao servidor de API. Use esses controles para ajudar a proteger o AKS da mesma forma que você faz para o acesso à assinatura do Azure.
Limite o acesso a ações que os contêineres podem executar. Use o recurso Admissão de segurança do pod para habilitar a autorização refinada de criação e atualizações do pod. Forneça o menor número de permissões e evite o uso de escalonamento raiz ou privilegiado. Para obter mais informações, consulte Acesso seguro do pod aos recursos.
Evite executar contêineres como usuário raiz sempre que possível.
Use o módulo de segurança do kernel do AppArmor Linux para limitar as ações que os contêineres podem fazer.
Atualize seus clusters AKS para a versão mais recente do Kubernetes regularmente para aproveitar os novos recursos e correções de bugs.
Use o daemonset kured para observar reinicializações pendentes, nós de cordão e drenagem e aplicar atualizações. O AKS baixa e instala automaticamente correções de segurança em cada nó Linux, mas não reinicia automaticamente o nó, se necessário. Para nós do Windows Server, execute regularmente uma operação de atualização do AKS para conectar e drenar pods com segurança e implantar quaisquer nós atualizados.
Considere o uso de protocolos de transporte seguro HTTPS e gRPC para todas as comunicações intrapod. E use um mecanismo de autenticação mais avançado que não exija que você envie as credenciais simples em todas as solicitações, como Open Authorization (OAuth) ou JSON Web Tokens (JWTs). Estabeleça uma comunicação intra-serviço mais segura usando uma malha de serviço, como Istio, Linkerd ou Consul. Ou você pode usar Dapr.
Container Registry
Analise suas imagens de contêiner em busca de vulnerabilidades e implante apenas imagens que passam na validação. Atualize regularmente as imagens base e o tempo de execução do aplicativo. Em seguida, reimplante cargas de trabalho no cluster AKS. Seu fluxo de trabalho de implantação de CI/CD deve incluir um processo para digitalizar imagens de contêiner. Você pode usar a segurança do Microsoft Defender for DevOps para verificar o código em busca de vulnerabilidades em seus pipelines automatizados durante as fases de compilação e implantação. Como alternativa, você pode usar ferramentas como Prisma Cloud ou Aqua para digitalizar e permitir que apenas imagens verificadas sejam implantadas.
Otimização de Custos
A Otimização de Custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.
O custo dessa arquitetura depende de aspetos de configuração, como os seguintes componentes:
- Escalões de serviço
- Escalabilidade ou o número de instâncias que os serviços alocam dinamicamente para dar suporte a uma determinada demanda
- Scripts de automatização
- Seu nível de recuperação de desastres
Depois de avaliar esses aspetos, use a calculadora de preços do Azure para estimar seus custos. Para obter mais informações, consulte os princípios do Well-Architected Framework de otimização de custos.
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 Lista de verificação de revisão de design para excelência operacional.
Armazenamento
Considere implantar seu cluster AKS com discos efêmeros do sistema operacional que fornecem menor latência de leitura e gravação, juntamente com escalonamento de nó mais rápido e atualizações de cluster.
Entenda as necessidades do seu aplicativo para escolher o armazenamento certo. Use armazenamento de alto desempenho apoiado por SSD para cargas de trabalho de produção. Planeje um sistema de armazenamento baseado em rede, como o Azure Files, quando vários pods precisarem acessar simultaneamente os mesmos arquivos. Para obter mais informações, consulte Opções de armazenamento para aplicativos no AKS.
Planeje as demandas de seu aplicativo para que você implante o tamanho apropriado dos nós. Cada tamanho de nó suporta um número máximo de discos. Diferentes tamanhos de nós também fornecem diferentes quantidades de armazenamento local e largura de banda de rede.
Use o provisionamento dinâmico. Para reduzir a sobrecarga de gerenciamento e habilitar o dimensionamento, não crie e atribua volumes persistentes estaticamente. Em suas classes de armazenamento, defina a política de recuperação apropriada para minimizar os custos de armazenamento desnecessários depois de excluir pods.
DevOps
Use um sistema de DevOps, como GitHub Actions ou Azure DevOps, para implantar suas cargas de trabalho no AKS por meio de um gráfico Helm em um pipeline de CI/CD. Para obter mais informações, veja Compilar e implementar no AKS.
Introduza testes A/B e implantações canárias no gerenciamento do ciclo de vida do aplicativo para testar corretamente um aplicativo antes de apresentá-lo a todos os usuários. 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 gerenciamento de tráfego que uma malha de serviço fornece. Para obter mais informações, consulte Gerenciamento de tráfego do Istio.
Use o Registro de Contêiner ou outro armazenamento de registro, como o Docker Hub, para catalogar e servir as imagens privadas do Docker que você implanta no cluster. O AKS pode usar sua identidade Microsoft Entra para autenticar com o Registro de Contêiner.
Se você precisar alterar as configurações no Application Gateway, faça a alteração usando a configuração exposta no controlador de entrada ou em outros objetos do Kubernetes, como usar anotações suportadas. Depois de vincular um gateway de aplicativo ao AGIC, o controlador de entrada sincroniza e controla quase todas as configurações desse gateway. Se você configurar diretamente o Application Gateway imperativamente ou por meio da infraestrutura como código, o controlador de entrada eventualmente substituirá essas alterações.
Monitorização
Considere as opções de monitoramento integradas ao Azure para monitorar o status de integridade do cluster AKS e das cargas de trabalho.
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 e enviá-los para o Log Analytics.
Eficiência de Desempenho
Eficiência de desempenho é a capacidade de sua carga de trabalho de escalar para atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.
As considerações de desempenho não dizem totalmente respeito à multilocação no AKS, mas são requisitos essenciais desta solução:
Para cargas de trabalho de baixa latência, considere implantar um pool de nós dedicados em um grupo de posicionamento de proximidade. Quando você implanta seu aplicativo no Azure, as instâncias de VM espalhadas por regiões ou zonas de disponibilidade criam latência de rede, o que pode afetar o desempenho geral do seu aplicativo. Um grupo de posicionamento de proximidade é um agrupamento lógico que você pode usar para garantir que os recursos de computação do Azure estejam fisicamente localizados próximos uns dos outros. Alguns casos de uso, como jogos, simulações de engenharia e negociação de alta frequência, exigem baixa latência e tarefas que são concluídas rapidamente. Para cenários de computação de alto desempenho como estes, considere o uso de grupos de posicionamento de proximidade para os pools de nós do cluster.
Use sempre imagens de contêiner menores porque você pode criar compilações mais rápidas. Imagens menores também são menos vulneráveis a vetores de ataque devido a uma superfície de ataque reduzida.
Use o dimensionamento automático do Kubernetes para dimensionar dinamicamente o número de nós de trabalho em um cluster AKS quando o tráfego aumentar. Com o Horizontal Pod Autoscaler e um autoscaler de cluster, os volumes de nós e pods são ajustados dinamicamente em tempo real para corresponder à condição de tráfego e evitar tempos de inatividade causados por problemas de capacidade. Para obter mais informações, consulte Usar o autoscaler de cluster no AKS.
Agendador
Revise e implemente as práticas recomendadas para operadores de cluster e desenvolvedores de aplicativos criarem e executarem aplicativos com êxito no AKS.
Planeje e aplique cotas de recursos no nível de namespace para todos os namespaces. Se os pods não definirem solicitações e limites de recursos, rejeite a implantação. Monitore o uso de recursos e, em seguida, ajuste as cotas conforme necessário. Quando várias equipes ou locatários compartilham um cluster AKS que tem um número fixo de nós, você pode usar cotas de recursos para atribuir uma parte justa dos recursos a cada equipe ou locatário.
Adote intervalos de limite para restringir alocações de recursos a pods ou contêineres em um namespace, em termos de CPU e memória.
Defina solicitações de recursos e limites explicitamente para o uso de CPU e memória para seus pods nos manifestos YAML ou gráficos Helm que você usa para implantar aplicativos. Quando você especifica a solicitação de recurso para contêineres em um pod, o agendador do Kubernetes usa essas informações para decidir em qual nó colocar o pod. Quando você especifica um limite de recursos para um contêiner, como a CPU ou a memória, o kubelet impõe esses limites para que o contêiner em execução não possa usar mais desse recurso do que o limite definido.
Mantenha a disponibilidade de aplicativos definindo orçamentos de interrupção de pod para garantir que um número mínimo de pods esteja disponível no cluster.
Use classes de prioridade para indicar a importância de um pod. Se o agendador não puder agendar um pod, ele tentará antecipar ou remover pods de prioridade mais baixa para que possa agendar o pod pendente.
Use as manchas e tolerâncias do Kubernetes para colocar aplicativos que consomem muitos recursos em nós específicos e para evitar problemas de vizinhos barulhentos. Mantenha os recursos do nó disponíveis para cargas de trabalho que os exigem. Não permita que outras cargas de trabalho sejam agendadas nos nós.
Use seletores de nós, afinidade de nó ou afinidade entre pods para controlar o agendamento de pods em nós. Use as configurações de afinidade e antiafinidade entre pods para colocalizar pods que tenham comunicações tagarelas, para colocar pods em nós diferentes e para evitar executar várias instâncias do mesmo tipo de pod no mesmo nó.
Implementar este cenário
O código-fonte para este cenário está disponível no GitHub. O diagrama a seguir mostra um aplicativo de demonstração que você pode encontrar no repositório AGIC GitHub multilocatário AKS.
Transfira um ficheiro do Visio desta arquitetura.
Pré-requisitos
Para implantações online, você deve ter uma conta existente do Azure. Se você não tiver uma, crie uma conta gratuita do Azure antes de começar.
Implementar no Azure
Certifique-se de que tem as informações da sua subscrição do Azure à mão.
Clone o repositório GitHub da bancada de trabalho:
git clone https://github.com/Azure-Samples/aks-agic.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
- Práticas recomendadas do cluster AKS
- Práticas recomendadas para recursos básicos do agendador no AKS
- Criar um cluster AKS privado
- Criar políticas WAF para o Application Gateway
- Diferença entre uma implantação Helm e o complemento AKS
- Como funciona um gateway de aplicativo