Desdobramento de um Wildcard Azure Application Gateway usando Powershell
Azure Application Gateway já existe há alguns anos. Ao longo dos últimos anos, nós o vimos mudar do padrão original (V1) sem nenhuma funcionalidade de Firewall de Aplicação Web para o padrão mais recente (V2) com ou sem a funcionalidade WAF. A versão v2 foi lançada em 30 de abril de 2019, então provavelmente já substituiu a maior parte do seu V1 (ou se você quiser começar de novo, o V2 é provavelmente o caminho a seguir)
Como funciona um Application Gateway?
Apenas como um lembrete, como funciona exactamente um Portal de Aplicações Azure:
Como ilustrado na imagem acima, você pode colocar um Azure Application Gateway entre clientes (web)- por exemplo, usuários que querem se conectar ao seu website – e o(s) seu(s) servidor(es) backend. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 – TCP e UDP) e encaminham o tráfego baseado no endereço IP de origem e porta, para um endereço IP de destino e porta.
Application Gateway pode tomar decisões de roteamento baseadas em atributos adicionais de uma requisição HTTP, por exemplo, caminho URI ou cabeçalhos de host. Por exemplo, você pode rotear o tráfego com base no URL de entrada. Assim, se a /imagens está na URL de entrada, você pode rotear o tráfego para um conjunto específico de servidores (conhecido como um pool) configurado para imagens. Se /video estiver na URL, esse tráfego é encaminhado para outro pool otimizado para vídeos.
Este tipo de roteamento é conhecido como balanceamento de carga da camada de aplicação (camada OSI 7). O Azure Application Gateway pode fazer roteamento baseado em URL e muito mais. Se quiser saber mais sobre todas as funcionalidades que uma aplicação tem, consulte este site
Agora introduzindo: Wildcard Application Gateway
Então, para aqueles de vocês que têm implantado Application Gateways no passado, seja através do uso de modelos ARM, Azure CLI ou Powershell, provavelmente saberão que o processo de implantação de um AGW é bastante incômodo, especialmente quando você quer definir múltiplos ouvintes e/ou configurações de backend HTTP. Pessoalmente, eu tenho implantado Gateways de Aplicações no passado que consistiam em 15 ouvintes e configurações de backend subseqüentes, todos terminando no mesmo nome de domínio.
Por exemplo:
www.contoso.com;
Contoso.com;
Meu.contoso.com;
Etc.
O problema com uma configuração como esta é que foi muito trabalho criar os ouvintes, associando-os a uma regra que por sua vez está associada a uma configuração de backend e HTTP. E você tinha que fazer isso para cada hostname que você queria configurar, apesar de todos eles compartilharem o mesmo domínio.
Mas desde 20 de julho de 2020, a Microsoft anunciou que agora eles também vão suportar a opção de definir nomes de host wildcard em um ouvinte multi-site. E você pode usar até 5 hostnames únicos por ouvinte. Não é fantástico?
Então como isso funciona exactamente é ilustrado abaixo:
Como pode ver na imagem acima, existem múltiplos ouvintes ‘multi-site’ configurados neste gateway de aplicação:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Estes ouvintes podem então ser encaminhados para os mesmos ou diferentes pools backend.
Então, usando um caractere wildcard no nome do host, você pode combinar vários nomes de host em um único ouvinte. Por exemplo, *.contoso.com pode combinar com ecom.contoso.com, b2b.contoso.com assim como cliente1.b2b.contoso.com e assim por diante. Usando um array de nomes de host, você pode configurar mais de um nome de host para um ouvinte, para encaminhar pedidos para um pool backend. Por exemplo, um ouvinte pode conter contoso.com, fabrikam.com que aceitará pedidos para ambos os nomes de host.
As advertências dos ouvintes wildcard
Os ouvintes wildcard ainda estão em pré-visualização, há algumas considerações e limitações a levar em conta:
1. Esta funcionalidade está em pré-visualização e está disponível apenas para Standard_v2 e WAF_v2 SKU do Application Gateway.
2. Esta funcionalidade está actualmente disponível apenas através do Azure PowerShell e do Azure CLI. O suporte ao portal está a chegar em breve. Por favor note que como o suporte ao portal não está totalmente disponível, se estiver a utilizar apenas o parâmetro HostNames, o ouvinte irá aparecer como um ouvinte básico no portal e a coluna Host name da vista de listagem do ouvinte não irá mostrar os nomes dos anfitriões que estão configurados. Para quaisquer alterações a um wildcard listener, certifique-se que usa o Azure PowerShell ou CLI até que este seja suportado no portal. Eu irei compartilhar algumas screenshots sobre isso mais abaixo neste blog.
3. Você não pode criar uma regra de redirecionamento com um ouvinte alvo que usa wildcard ou vários nomes de host. Então você não pode criar um redirecionamento HTTP para HTTPS como você pode em uma configuração de um ouvinte que não seja um wildcard.
4. Para verificação do estado do backend, você não pode associar múltiplas sondas personalizadas por configurações HTTP. Em vez disso, você pode sondar um dos sites no backend ou usar “127.0.0.1” para sondar o localhost do servidor backend. Entretanto, quando você estiver usando wildcard ou vários nomes de host em um ouvinte, os pedidos para todos os padrões de domínio especificados serão roteados para o pool do backend, dependendo do tipo de regra (básica ou baseada em caminho).
5. Você não pode usar uma expressão regular para mencionar o nome do host. Você só pode usar caracteres curinga como asterisco (*) e ponto de interrogação (?) para formar o host name pattern.
6. Se vários nomes de host forem mencionados no mesmo ouvinte, você deve carregar um certificado SAN (Subject Alternative Names) com os CNs correspondentes aos nomes de host mencionados.
7. Se for um wildcard hostname como *.contoso.com, você deve carregar um wildcard certificate com CN como *.contoso.com
Suficiente com a teoria! Como eu implanto?
Como mencionado anteriormente, no momento de escrever este blog, você pode tanto o usuário Powershell ou Azure CLI.
Eu tenho um exemplo de Powerhell que vai fazer o seguinte:
1. Encontre a VNET e Subnet approriate para implantar o AGW em.
2. Crie um endereço IP público para ser usado pelo AGW
3. Crie configurações IP para o Gateway e o frontend
4. Crie backend-pools
5. Criar ouvintes e regras de roteamento
6. Criar a política de Firewall para Aplicações Web
7. Configurar as configurações da política TLS
8. Criar o gateway da aplicação (neste ponto será apenas um AGW HTTP)
Então, após o AGW ter sido implantado com sucesso, o script adicionará HTTPS ao gateway da aplicação:
9. Encontre o AGW e armazene-o em uma variável
10. Adicione o certificado SSL (PFX + senha necessária) e armazene-o em uma variável
11. Adicione a porta do ouvinte HTTPS e guarde-a numa variável
12. Obtenha a configuração do IP frontend e armazene-a em uma variável
13. Adicione um ouvinte frontend (HTTPS) e armazene-o em uma variável
14. Pegue o backendpool e armazene-o em uma variável
15. Adicione configurações do backend HTTP e armazene-o em uma variável
16. Anexe todos os togheter acima em uma Regra de Roteamento
17. Atualize o Application Gateway com tudo criado nos passos 8-15.
O script powerhell
Antes de poder executar o script powerhell, há algumas coisas que você precisa fazer:
1. Entre no Azure, usando o powershell (login-azAccount)
2. Encontre a assinatura na qual você quer implantar (get-azSubscription)
3. Selecione essa assinatura (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Certifique-se de ter criado uma VNET e uma Subnet na sua assinatura, que seja capaz de implantar o AGW. Para o dimensionamento de sub-rede, recomenda-se o uso de uma sub-rede /26 como minium.
5. Se você tiver uma VNET e sub-redes funcionando em um grupo de recursos de sua escolha, preencha os seguintes parâmetros com as informações apropriadas:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)
6. O resto das variáveis é realmente com você. Porque pode haver coisas envolvidas como convenção de nomes, configurações de timeout, etc. Eu não vou recomendar nada aqui. Meu script é baseado em um único wildcard listener com um único backend e algumas configurações padrão de http, mas fique à vontade para editá-las a seu gosto.
7. Atenção especial vai para as configurações WAF & SSL/TLS. Este script habilitará o WAF para você e criará uma política WAF no mesmo grupo de recursos em que o Application Gateway será implantado. Esta política WAF é então vinculada ao AGW. Para configurações SSL/TLS eu estou ativando a última pré-configuração (melhores práticas) de policysetting.
Qual será o resultado?
Após ter executado o script powerhell, você vai acabar com um grupo de recursos que tem os seguintes recursos:
1. O próprio Application Gateway
2. Um endereço IP público que está vinculado ao Application Gateway
3. Uma Política de Firewall de Aplicações Web personalizada que está vinculada ao Application Gateway
Espero que este post ajude você a implantar e configurar o Wildcard Application Gateway que você deseja!
Ligações úteis:
O script Powershell no github
Microsoft documentation
Leave a Reply