--- name: azion-bind-a-firewall-to-a-workload description: >- 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. --- # Bind a firewall to a workload You can bind an existing [firewall](/en/documentation/platform/firewall/) to a [workload](/en/documentation/platform/workloads/) from Azion Console, the [Azion CLI](/en/documentation/devtools/cli/), or the API. To create a firewall, add its first rule, and bind it in one pass, refer to [Firewall quickstart](/en/documentation/platform/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](/en/documentation/platform/workloads/how-it-works/#the-deployment). 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](/en/documentation/platform/workloads/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](/en/documentation/platform/workloads/). - A firewall with the rules the workload needs. To create a firewall, refer to [Firewall quickstart](/en/documentation/platform/firewall/quickstart/). To add rules to it, refer to [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine/). **Console** - Access to Azion Console. For more information, refer to [Access Azion Console](/en/documentation/guides/platform/account-and-billing/how-to-access-azion-console/). **CLI** - The [Azion CLI](/en/documentation/devtools/cli/), authorized with your account. This page matches Azion CLI 4.23.0. - The workload ID, the ID of the application the workload serves, and the firewall ID. The address of a firewall's page in Azion Console carries its ID after `/firewalls/edit/`. **API** - A personal token for the `Authorization` header, in the form `Token [TOKEN VALUE]`. To create a token, refer to [Manage a personal token](/en/documentation/guides/platform/account-and-billing/personal-tokens/). - `curl` or another HTTP client. - The workload ID, the ID of the application the workload serves, and the firewall ID. The address of a firewall's page in Azion Console carries its ID after `/firewalls/edit/`. - The ID of the workload's deployment. A `GET` request to `/v4/workspace/workloads//deployments` returns the deployment with its `id`. --- ## Bind the firewall to the workload A deployment carries exactly three settings: its application, its firewall, and its [custom page set](/en/documentation/platform/workloads/custom-pages/settings/). 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](/en/documentation/platform/workloads/settings/#deployment). **Console** To bind the firewall in Azion Console: 1. **Open the Workloads page** Access [Azion Console](https://console.azion.com/) > **Workloads**. 2. **Open the workload** Select the workload whose domains the firewall protects. Its edit form opens. 3. **Select your firewall** 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. 4. **Save the workload** Select **Save**. After the save, the deployment of the workload names your firewall. **CLI** 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: ```bash azion create workload-deployment --workload-id \ --name --application-id \ --firewall-id --strategy-type default --active true --current true ``` The command prints the ID of the deployment it created: ```text Created Workload Deployment with ID ``` `--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 ` to the command. **API** To bind the firewall with the API, send a `PATCH` request to the workload's deployment. Send the whole `strategy` object: the application the workload serves, the firewall ID in `strategy.attributes.firewall`, and, if the workload uses a custom page set, its ID in `strategy.attributes.custom_page`: ```bash curl --request PATCH \ --url https://api.azion.com/v4/workspace/workloads//deployments/ \ --header 'Accept: application/json' \ --header 'Authorization: Token [TOKEN VALUE]' \ --header 'Content-Type: application/json' \ --data '{ "strategy": { "type": "default", "attributes": { "application": , "firewall": } } }' ``` The API answers `202`, and the deployment names your firewall. --- ## 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](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine/). 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](/en/documentation/platform/firewall/how-it-works/#propagation). Send a request to the denied path. Replace `` with a domain the workload serves, such as its workload domain of the form `.map.azionedge.net`: ```bash curl -i https:///deny-test ``` The firewall refuses the request with `403`. This excerpt of the response leaves out its long `content-security-policy` header: ```text HTTP/2 403 server: nginx date: Thu, 01 Jan 2026 12:00:00 GMT content-type: text/html; charset=utf-8 x-content-type-options: nosniff x-azion-request-id: 0123456789abcdef0123456789abcdef x-azion-edge-location: alt-svc: h3=":443"; ma=86400 ``` 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](/en/documentation/platform/firewall/troubleshooting/). --- ## Next steps - [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine.md): Add a rule that denies one path, or a rule that requires a client certificate. - [WAF quickstart](/en/documentation/platform/firewall/waf/quickstart.md): Apply a WAF rule set to the firewall with a Set WAF behavior and see an injection-shaped request refused. - [Firewall best practices](/en/documentation/platform/firewall/best-practices.md#share-one-firewall-among-workloads-with-the-same-security-policy): Decide when workloads share one firewall, and what a change to it then reaches. - [Troubleshoot Firewall](/en/documentation/platform/firewall/troubleshooting.md): Find why a bound firewall does not act on the requests a workload receives.