Bind a firewall to a workload
Protect the domains of a workload with an existing firewall: name it in the workload's deployment from Azion Console or the Azion CLI.
You can bind an existing firewall to a workload from Azion Console or the Azion CLI. To create a firewall, add its first rule, and bind it in one pass, refer to Firewall quickstart.
A firewall has no domain of its own. The workload carries the domains, and its deployment names the firewall that inspects their requests. The workload record itself holds no firewall field, so the binding lives on the deployment. For more information, refer to How Workloads works.
An account that runs on API v3 with Domains binds a firewall in the settings of each domain instead. For more information, refer to Domains.
Prerequisites
Console
- A workload that serves an application. For more information, refer to Workloads.
- A firewall with the rules the workload needs. To create a firewall, refer to Firewall quickstart. To add rules to it, refer to Create a firewall rule.
- Access to Azion Console. For more information, refer to Access Azion Console.
Bind the firewall to the workload
A deployment carries exactly three settings: its application, its firewall, and its custom page set. The application and the custom page set stay the ones the workload uses today, so the firewall is the only setting that changes. Until a deployment names the firewall, the firewall’s rules see no request to the workload.
A workload holds one deployment, so you change the deployment it has. A second deployment is refused with The maximum number of deployments allowed per workload is 1. For every field of the deployment, refer to Workload settings.
Console
To bind the firewall in Azion Console:
Access Azion Console > Workloads.
Select the workload whose domains the firewall protects. Its edit form opens.
In the Deployment Settings section, select your firewall in the Firewall field. In a workload with no firewall, the field reads Select a Firewall.
Application and Custom Page keep the values the workload serves today.
Select Save.
After the save, the deployment of the workload names your firewall.
Bind the firewall to a v3 domain
An account that runs on API v3 has Domains in place of workloads, and binds the firewall on the domain itself rather than on a deployment. To find out which model your account runs on, refer to Verify your account migration.
To bind a firewall to a domain in Azion Console:
Access Azion Console > Domains > the domain you want the firewall to protect.
In the Settings section, open the Firewall selector and choose the firewall.
Select Save.
The firewall then inspects the requests of that domain. The confirmation check reads the response of a request, whichever model served it.
Confirm that the firewall applies its rules
The check is the same for every interface. It needs a firewall rule whose answer you can recognize. This section uses a rule that denies every path that starts with /deny-test, such as the one in Create a firewall rule.
The firewall’s rules can take several minutes to take effect on the workload after the binding, and no duration is guaranteed. Until then, requests reach your application as before. While the binding spreads, answers to the same request alternate between the old result and the new one. Repeat the request until it returns 403. For more information, refer to How Firewall works.
Send a request to the denied path. Replace <your-domain> with a domain the workload serves, such as its workload domain of the form <id>.map.azionedge.net:
The firewall refuses the request with 403. This excerpt of the response leaves out its long content-security-policy header:
The body is Azion’s default error page, headed Forbidden, and it shows your IP address and the request ID. No response header identifies the firewall or the rule behind the refusal. Paths that no rule matches still reach your application.
If /deny-test keeps reaching your application after the binding has had several minutes to propagate, refer to Troubleshoot Firewall.