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, the Azion CLI, or the API.
You can bind an existing firewall to a workload from Azion Console, the Azion CLI, or the API. 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.
Select an interface. The prerequisites and the steps that bind the firewall follow your choice.
Prerequisites
- 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.
The Azion CLI binds a firewall only when it creates the workload’s deployment. Azion CLI 4.23.0 has no command that changes an existing deployment, so for a workload that already serves an application, use the Console or the API.
To bind the firewall as the CLI creates the deployment, name the firewall beside the application:
The command prints the ID of the deployment it created:
--current true makes this deployment the one the workload runs. A deployment created this way reads "custom_page": null. To assign a custom page set, add --custom-page <custom-page-id> to the command.
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.