Partilhar via

Preparar para implantar a carga de trabalho do aplicativo Web da Amazon Web Services (AWS) no Azure

Este artigo fornece um guia abrangente sobre como implantar uma infraestrutura robusta e pronta para produção para facilitar a hospedagem, proteção, dimensionamento e monitoramento de um aplicativo Web na plataforma Azure.

Implantação do Yelb na AWS

O aplicativo web de exemplo Yelb na AWS é implantado usando Bash, AWS CLI, eksctl, kubectl e Helm. O exemplo complementar contém scripts Bash e manifestos YAML que você pode usar para automatizar a implantação do aplicativo Yelb no AWS Elastic Kubernetes Service (EKS). Esta solução demonstra como implementar um firewall de aplicativo da web usando o AWS WAF para proteger um aplicativo da web em execução no Amazon Elastic Kubernetes Service (EKS). Você pode usar os scripts Bash para criar um cluster EKS e implantar o aplicativo Yelb . O aplicativo da web Yelb é exposto à Internet pública usando um Amazon Application Load Balancer (ALB) e protegido usando a lista de controle de acesso à web (ACL da web) do AWS WAF. Para obter instruções detalhadas, consulte Portabilidade de um aplicativo Web do AWS Elastic Kubernetes Service (EKS) para o Azure Kubernetes Service (AKS).

Screenshot da interface do serviço Yelb.

Implementação do Yelb no Azure

Nas seções a seguir, você aprenderá como implantar o aplicativo Web de exemplo Yelb em um cluster do Serviço Kubernetes do Azure (AKS) e expô-lo por meio de um controlador de entrada como o controlador de entrada NGINX. O serviço de controlador de entrada é acessível através de um balanceador de carga interno (ou privado), que equilibra o tráfego dentro da rede virtual que abriga o cluster AKS. Em um cenário híbrido, o front-end do balanceador de carga pode ser acessado de uma rede local. Para saber mais sobre o balanceamento de carga interno, consulte Usar um balanceador de carga interno com o Serviço Kubernetes do Azure (AKS).

O exemplo complementar suporta a instalação de um controlador de entrada NGINX gerenciado com o complemento de roteamento de aplicativo ou um controlador de entrada NGINX não gerenciado usando o gráfico Helm. O complemento de roteamento de aplicativos com controlador de ingresso NGINX fornece os seguintes recursos:

Para outras configurações,

Para aumentar a segurança, o aplicativo Yelb é protegido por um recurso do Azure Application Gateway . Este recurso é implantado em uma sub-rede dedicada dentro da mesma rede virtual que o cluster AKS ou em uma rede virtual emparelhada. O Firewall de Aplicativo Web do Azure (WAF) protege o acesso ao aplicativo Web hospedado no Serviço Kubernetes do Azure (AKS) e exposto por meio do Gateway de Aplicativo do Azure contra explorações e vulnerabilidades comuns.

Pré-requisitos

  • Uma assinatura ativa do Azure. Se você não tiver uma, crie uma conta gratuita do Azure antes de começar.
  • A função interna do Azure Proprietário, ou as funções internas de Administrador de Acesso de Usuário e Colaborador, em uma assinatura na sua conta do Azure.
  • CLI do Azure versão 2.61.0 ou posterior. Para obter mais informações, consulte Instalar a CLI do Azure.
  • Extensão de visualização do Serviço Kubernetes do Azure (AKS).
  • JQ versão 1.5 ou posterior.
  • Python 3 ou posterior.
  • Kubectl versão 1.21.0 ou posterior
  • Helm versão 3.0.0 ou posterior
  • Visual Studio Code instalado numa das plataformas suportadas junto com a extensão Bicep.
  • Um recurso existente do Azure Key Vault com um certificado TLS válido para o aplicativo Web Yelb.
  • Uma Zona DNS do Azure existente ou um servidor DNS equivalente para a resolução de nomes da aplicação Yelb.

Arquitetura

Este exemplo fornece uma coleção de modelos Bicep, scripts Bash e manifestos YAML para criar um cluster AKS, implantar o aplicativo Yelb, expor o serviço de interface do usuário usando o controlador de entrada NGINX e protegê-lo com o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web do Azure (WAF).

Este exemplo também inclui dois arquivos de parâmetros Bicep separados e dois conjuntos de scripts Bash e manifestos YAML, cada um voltado para a implantação de duas opções de solução diferentes. Para obter mais informações sobre o Bicep, consulte O que é o Bicep?

Terminação TLS no Application Gateway e invocação Yelb via HTTP

Nesta solução, o Azure Web Application Firewall (WAF) garante a segurança do sistema bloqueando ataques mal-intencionados. O Gateway de Aplicativo do Azure recebe chamadas de entrada de aplicativos cliente, executa a terminação TLS e encaminha as solicitações para o serviço hospedado pelo yelb-ui AKS. Essa comunicação é realizada através do balanceador de carga interno e do controlador de entrada NGINX usando o protocolo de transporte HTTP. O diagrama a seguir ilustra a arquitetura:

Diagrama da solução baseada em Application Gateway WAFv2 e NGINX ingress controller via HTTP.

O fluxo de mensagens é o seguinte:

Diagrama do fluxo de mensagens da solução baseada no Application Gateway WAFv2 e controlador de entrada NGINX via HTTP.

  1. O Gateway de Aplicativo do Azure lida com a terminação TLS e envia chamadas de entrada para o serviço hospedado pelo yelb-ui AKS por HTTP.
  2. O Application Gateway Listener usa um certificado SSL obtido do Azure Key Vault para garantir uma comunicação segura.
  3. A Política WAF do Azure associada ao Ouvinte aplica regras OWASP e regras personalizadas a solicitações de entrada, prevenindo efetivamente muitos tipos de ataques mal-intencionados.
  4. As Configurações HTTP do Back-end do Application Gateway invocam o aplicativo Yelb via HTTP usando a porta 80.
  5. O Pool de Back-end do Application Gateway e a Sonda de Integridade chamam o controlador de entrada NGINX por meio do balanceador de carga interno do AKS usando o protocolo HTTP para gerenciamento de tráfego.
  6. O controlador de entrada NGINX usa o balanceador de carga interno AKS para garantir uma comunicação segura dentro do cluster.
  7. Um objeto de entrada do Kubernetes usa o controlador de entrada NGINX para expor o aplicativo via HTTP através do balanceador de carga interno.
  8. O yelb-ui serviço com o ClusterIP tipo restringe sua invocação para dentro do cluster ou através do controlador de entrada NGINX.

Implementando TLS de ponta a ponta usando o Gateway de Aplicativo do Azure

Terminação TLS

O Gateway de Aplicativo do Azure dá suporte à terminação TLS no nível do gateway, o que significa que o tráfego é descriptografado no gateway antes de ser enviado para os servidores back-end. Para configurar a terminação TLS, você precisa adicionar um certificado TLS/SSL ao ouvinte. O certificado deve estar no formato de Troca de Informações Pessoais (PFX), que contém as chaves privada e pública. Você pode importar o certificado do Cofre da Chave do Azure para o Gateway de Aplicativo. Para obter mais informações, veja Terminação TLS com certificados do Key Vault.

Modelo de segurança Zero Trust

Se você adotar um modelo de segurança Zero Trust , deverá impedir a comunicação não criptografada entre um proxy de serviço como o Gateway de Aplicativo do Azure e os servidores back-end. Com o modelo de segurança Zero Trust, a confiança não é concedida automaticamente a nenhum usuário ou dispositivo que tente acessar recursos em uma rede. Em vez disso, requer verificação contínua de identidade e autorização para cada solicitação, independentemente da localização ou rede do usuário. Em nosso cenário, a implementação do modelo de segurança Zero Trust envolve o uso do Gateway de Aplicativo do Azure como um proxy de serviço, que atua como um front-end para solicitações de entrada. Em seguida, essas solicitações viajam até o controlador de entrada NGINX no Serviço Kubernetes do Azure (AKS) em um formato criptografado.

TLS de ponta a ponta com Application Gateway

Você pode implementar uma abordagem Zero Trust configurando o Gateway de Aplicativo do Azure para criptografia TLS de ponta a ponta com os servidores back-end. A criptografia TLS de ponta a ponta permite transmitir dados confidenciais com segurança para o back-end enquanto aproveita os recursos de balanceamento de carga de camada 7 do Application Gateway, incluindo afinidade de sessão baseada em cookie, roteamento baseado em URL, roteamento baseado em sites e a capacidade de reescrever ou injetar cabeçalhos X-Forwarded-*.

Quando o Application Gateway é configurado com o modo de comunicação TLS de ponta a ponta, ele encerra as sessões TLS no gateway e descriptografa o tráfego do usuário. Em seguida, ele aplica as regras configuradas para selecionar a instância apropriada do pool de back-end para a qual rotear o tráfego. Em seguida, o Application Gateway inicia uma nova conexão TLS com o servidor back-end e criptografa novamente os dados usando o certificado de chave pública do servidor back-end antes de transmitir a solicitação para o back-end. A resposta do servidor web segue o mesmo processo antes de chegar ao usuário final. Para habilitar o TLS de ponta a ponta, você precisa definir a configuração de protocolo na Configuração HTTP de back-end como HTTPS e aplicá-la a um pool de back-end. Essa abordagem garante que sua comunicação com os servidores back-end seja segura e compatível com seus requisitos.

Para obter mais informações, consulte Criptografia TLS de ponta a ponta do Application Gateway e Práticas recomendadas para proteger seu Application Gateway.

Nesta solução, o Azure Web Application Firewall (WAF) garante a segurança do sistema bloqueando ataques mal-intencionados. O Gateway de Aplicativo do Azure lida com chamadas de entrada de aplicativos cliente, executa a terminação TLS e implementa TLS de ponta a ponta invocando o serviço subjacente hospedado yelb-ui pelo AKS usando o protocolo de transporte HTTPS por meio do balanceador de carga interno e do controlador de entrada NGINX. O diagrama a seguir ilustra a arquitetura:

Diagrama da solução baseada em Application Gateway WAFv2 e NGINX ingress controller via HTTPS.

O fluxo de mensagens é o seguinte:

  1. O Gateway de Aplicativo do Azure lida com a terminação TLS e se comunica com o aplicativo back-end por HTTPS.
  2. O Escutador do Gateway de Aplicação usa um certificado SSL obtido do Cofre de Chaves do Azure.
  3. A Política WAF do Azure associada ao Ouvinte executa regras OWASP e regras personalizadas contra solicitações de entrada para bloquear ataques mal-intencionados.
  4. As Configurações HTTP de Back-end do Application Gateway são configuradas para invocar o serviço hospedado pelo yelb-ui AKS via HTTPS na porta 443.
  5. O Pool de Back-end do Application Gateway e a Sonda de Integridade chamam o controlador de entrada NGINX por meio do balanceador de carga interno do AKS usando HTTPS.
  6. O controlador de entrada NGINX é implantado para usar o balanceador de carga interno AKS.
  7. O cluster SAKS está configurado com o add-on Azure Key Vault provider for Secrets Store CSI Driver para recuperar segredos, certificados e chaves do Azure Key Vault por meio de um volume CSI.
  8. Um SecretProviderClass é usado para recuperar o certificado usado pelo Application Gateway do Cofre da Chave.
  9. Um objeto de entrada do Kubernetes usa o controlador de entrada NGINX para expor o aplicativo via HTTPS através do balanceador de carga interno do AKS.
  10. O yelb-ui serviço tem um ClusterIP tipo, que restringe sua invocação para dentro do cluster ou através do controlador de entrada NGINX.

Para ajudar a garantir a segurança e a estabilidade do sistema, considere as seguintes recomendações:

  • Atualize regularmente a Política WAF do Azure com as regras mais recentes para garantir a segurança ideal.
  • Implemente mecanismos de monitoramento e registro para rastrear e analisar solicitações de entrada e possíveis ataques.
  • Realize regularmente manutenção e atualizações do cluster AKS, do controlador de entrada NGINX e do Application Gateway para resolver quaisquer vulnerabilidades de segurança e manter uma infraestrutura segura.
  • Implemente mecanismos de monitoramento e registro para rastrear e analisar solicitações de entrada e possíveis ataques.
  • Realize regularmente manutenção e atualizações do cluster AKS, do controlador de entrada NGINX e do Application Gateway para resolver quaisquer vulnerabilidades de segurança e manter uma infraestrutura segura.

Hostname (Nome do anfitrião)

O Application Gateway Listener e a entrada do Kubernetes são configurados para usar o mesmo nome de host. É importante usar o mesmo nome de host para um proxy de serviço e um aplicativo Web de back-end pelos seguintes motivos:

  • Preservação do estado da sessão: Quando você usa um nome de host diferente para o proxy e o aplicativo de back-end, o estado da sessão pode se perder. Isso significa que as sessões do usuário podem não persistir corretamente, resultando em uma experiência ruim do usuário e potencial perda de dados.
  • Falha de autenticação: Se o nome do host for diferente entre o proxy e o aplicativo de back-end, os mecanismos de autenticação poderão falhar. Essa abordagem pode fazer com que os usuários não consigam fazer login ou acessar recursos seguros dentro do aplicativo.
  • Exposição inadvertida de URLs: se o nome do host não for preservado, há um risco de que os URLs de back-end possam ser expostos aos usuários finais. Isso pode levar a possíveis vulnerabilidades de segurança e acesso não autorizado a informações confidenciais.
  • Problemas com cookies: Os cookies desempenham um papel crucial na manutenção de sessões de utilizador e na transmissão de informações entre o cliente e o servidor. Quando o nome do host é diferente, os cookies podem não funcionar conforme o esperado, levando a problemas como falha na autenticação, manipulação incorreta da sessão e redirecionamento incorreto.
  • Requisitos de TLS/SSL de ponta a ponta: Se TLS/SSL de ponta a ponta for necessário para comunicação segura entre o proxy e o serviço de back-end, um certificado TLS correspondente para o nome de host original será necessário. Usar o mesmo nome de host simplifica o processo de gerenciamento de certificados e garante que a comunicação segura seja estabelecida perfeitamente.

Você pode evitar esses problemas ao utilizar o mesmo nome de host para o proxy do serviço e a aplicação web backend. O aplicativo back-end vê o mesmo domínio que o navegador da Web, garantindo que o estado da sessão, a autenticação e a manipulação de URL funcionem corretamente.

Fluxo de mensagens

O diagrama a seguir mostra as etapas para o fluxo de mensagens durante a implantação e o tempo de execução.

Diagrama do fluxo de mensagens da solução baseada no Application Gateway WAFv2 e controlador de entrada NGINX via HTTPS.

Fluxo de trabalho de implantação

As etapas a seguir descrevem o processo de implantação. Este fluxo de trabalho corresponde aos números verdes no diagrama anterior.

  1. Um engenheiro de segurança gera um certificado para o domínio personalizado que a carga de trabalho usa e o salva em um cofre de chaves do Azure. Você pode obter um certificado válido de uma autoridade de certificação (CA) conhecida.
  2. Um engenheiro de plataforma especifica as informações necessárias no arquivo de parâmetros do Bicep main.bicepparams e implanta os modelos do Bicep para criar os recursos do Azure. As informações necessárias incluem:
    • Um prefixo para os recursos do Azure.
    • O nome e o grupo de recursos do Cofre da Chave do Azure existente que contém o certificado TLS para o nome do host da carga de trabalho e o domínio personalizado do ouvinte do Gateway de Aplicativo.
  3. Você pode configurar o script de implantação para instalar os seguintes pacotes no cluster AKS. Para obter mais informações, verifique a seção de parâmetros do módulo Bicep.
  4. O Ouvinte do Gateway de Aplicativo recupera o certificado TLS do Cofre de Chaves do Azure.
  5. O objeto de entrada do Kubernetes usa o certificado obtido do provedor do Azure Key Vault para o Driver CSI do Secrets Store para expor o serviço Yelb UI via HTTPS.
  6. O Application Gateway Listener recupera o certificado TLS do Cofre de chaves do Azure.
  7. O objeto ingress do Kubernetes utiliza o certificado obtido do provedor do Azure Key Vault para o Secrets Store CSI Driver para expor o serviço Yelb UI via HTTPS.

Fluxo de trabalho de tempo de execução

  1. O aplicativo cliente chama o aplicativo Web de exemplo usando seu nome de host. A zona DNS associada ao domínio personalizado do Listener do Application Gateway utiliza um registo A para resolver a consulta DNS com o endereço do IP público do Azure, usado pela configuração de IP de front-end do Application Gateway.
  2. A solicitação é enviada para o IP público do Azure usado pela configuração IP front-end do Gateway de Aplicativo.
  3. O Application Gateway executa as seguintes ações:
    1. O Application Gateway lida com a terminação TLS e se comunica com o aplicativo back-end por HTTPS.
    2. O Listener do Application Gateway usa um certificado SSL obtido do Azure Key Vault.
    3. A Política WAF do Azure associada ao Ouvinte executa regras OWASP e regras personalizadas contra a solicitação de entrada e bloqueia ataques mal-intencionados.
    4. As Definições HTTP de Back-end do Gateway de Aplicações são configuradas para invocar a aplicação web de exemplo via HTTPS na porta 443.
  4. O conjunto de servidores de back-end do Application Gateway chama o controlador de entrada do NGINX por meio do balanceador de carga interno do AKS usando HTTPS.
  5. A solicitação é enviada para um dos nós do agente que hospeda um pod do controlador de entrada NGINX.
  6. Uma das réplicas do NGINX ingress controller lida com a solicitação e envia-a para um dos pontos de extremidade do serviço yelb-ui.
  7. O yelb-ui chama o serviço yelb-appserver.
  8. O yelb-appserver chama os serviços yelb-db e yelb-cache.
  9. O yelb-ui chama o serviço yelb-appserver.
  10. O yelb-appserver chama os serviços yelb-db e yelb-cache.

Implantação

Por padrão, os modelos do Bicep instalam o cluster AKS com o plug-in de rede Azure CNI Overlay e o plano de dados Cilium. Você pode usar um plug-in de rede alternativo. Além disso, o projeto mostra como implantar um cluster AKS com as seguintes extensões e recursos:

Em um ambiente de produção, é altamente recomendável implantar um cluster AKS privado com SLA de tempo de atividade. Para obter mais informações, consulte Cluster AKS privado com um endereço DNS público.

Como alternativa, você pode implantar um cluster AKS público e proteger o acesso ao servidor de API usando intervalos de endereços IP autorizados. Para obter informações detalhadas e instruções sobre como implantar a infraestrutura no Azure usando modelos Bicep, consulte o exemplo de código complementar do Azure.

Em um ambiente de produção, é altamente recomendável implantar um cluster AKS privado com SLA de tempo de atividade. Para obter mais informações, consulte Cluster AKS privado com um endereço DNS público. Como alternativa, você pode implantar um cluster AKS público e proteger o acesso ao servidor de API usando intervalos de endereços IP autorizados. Para obter informações detalhadas e instruções sobre como implantar a infraestrutura no Azure usando modelos Bicep, consulte o exemplo de código complementar do Azure.

Próximo passo

Implantar uma carga de trabalho de aplicativo Web da AWS no Azure

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

Autor principal:

Outros contribuidores:

  • Last updated on