Vincule um firewall a um workload
Proteja os domínios de um workload com um firewall existente: nomeie-o no deployment do workload pelo Azion Console, pela Azion CLI ou pela API.
Você pode vincular um firewall existente a um workload pelo Azion Console, pela Azion CLI ou pela API. Para criar um firewall, adicionar a primeira regra dele e vinculá-lo de uma só vez, consulte Primeiros passos com Firewall.
Um firewall não tem domínio próprio. O workload traz os domínios, e o deployment dele nomeia o firewall que inspeciona as requisições a esses domínios. O registro do workload em si não tem campo de firewall, então o vínculo fica no deployment. Para mais informações, consulte Como Workloads funciona.
Uma conta que usa a API v3 com Domains vincula um firewall nas configurações de cada domínio, em vez disso. Para mais informações, consulte Domains.
Selecione uma interface. Os pré-requisitos e os passos que vinculam o firewall seguem a sua escolha.
Pré-requisitos
- Um workload que serve uma aplicação. Para mais informações, consulte Workloads.
- Um firewall com as regras de que o workload precisa. Para criar um firewall, consulte Primeiros passos com Firewall. Para adicionar regras a ele, consulte Crie uma regra de firewall.
- Acesso ao Azion Console. Para mais informações, consulte Como acessar o Azion Console.
Vincule o firewall ao workload
Um deployment tem exatamente três configurações: a aplicação, o firewall e o conjunto de custom pages dele. A aplicação e o conjunto de custom pages continuam as que o workload usa hoje, então o firewall é a única configuração que muda. Até que um deployment nomeie o firewall, as regras do firewall não veem nenhuma requisição ao workload.
Um workload tem um único deployment, então você altera o deployment que ele já tem. Um segundo deployment é recusado com The maximum number of deployments allowed per workload is 1. Para todos os campos do deployment, consulte Configurações de workload.
A Azion CLI vincula um firewall somente quando cria o deployment do workload. A Azion CLI 4.23.0 não tem um comando que altere um deployment existente, então, para um workload que já serve uma aplicação, use o Console ou a API.
Para vincular o firewall enquanto a CLI cria o deployment, nomeie o firewall ao lado da aplicação:
O comando imprime o ID do deployment que ele criou:
--current true torna este deployment o que o workload executa. Um deployment criado dessa forma mostra "custom_page": null. Para atribuir um conjunto de custom pages, adicione --custom-page <custom-page-id> ao comando.
Confirme que o firewall aplica as regras dele
A verificação é a mesma para todas as interfaces. Ela precisa de uma regra de firewall cuja resposta você reconheça. Esta seção usa uma regra que nega todo caminho que começa com /deny-test, como a de Crie uma regra de firewall.
As regras do firewall podem levar vários minutos para entrar em vigor no workload depois do vínculo, e nenhuma duração é garantida. Até lá, as requisições chegam à sua aplicação como antes. Enquanto o vínculo se propaga, as respostas à mesma requisição alternam entre o resultado antigo e o novo. Repita a requisição até que ela retorne 403. Para mais informações, consulte Como Firewall funciona.
Envie uma requisição para o caminho negado. Substitua <your-domain> por um domínio que o workload serve, como o domínio de workload dele, no formato <id>.map.azionedge.net:
O firewall recusa a requisição com 403. Este trecho da resposta omite o longo header content-security-policy:
O corpo é a página de erro padrão da Azion, com o título Forbidden, e mostra o seu endereço IP e o ID da requisição. Nenhum header da resposta identifica o firewall ou a regra por trás da recusa. Os caminhos aos quais nenhuma regra corresponde continuam chegando à sua aplicação.
Se /deny-test continuar chegando à sua aplicação depois que o vínculo teve vários minutos para se propagar, consulte Solucionar problemas de Firewall.