Skip to content

Firewall Rule Deployment

Operator runbook for the deployment of an approved and merged change to firewall rules or IP groups. Both live in the firewall layer. Read it with Firewall rules and Pipelines and workflows.

1. Before you start

  • The pull request is approved and merged to main.
  • You have access to the pipelines of the right platform and to the ticket.

2. Run the pipeline for canary

  1. Open the pipelines of the project and select the hub pipeline (hub).
  2. Run it from main. Where your entry pipeline lets you choose, select:
    • environment: canary;
    • layer: firewall;
    • region: the region of the change (for example weu), or every region that the change touches.
  3. Read the plan. Only the firewall layer may show changes, and only for the groups you touched (Check the plan).
  4. Approve it when it matches, and follow the run until it finishes.

How much you can choose at run time depends on the entry pipeline of your platform: some set the environment, the layer and the mode in the entry file (Parameters you will change).

Stop on a time-out

A change with many rule collection groups can run into the apply time-out, because Azure does not accept parallel updates of the same policy. If canary already shows time-outs, do not continue to production. Split the change into smaller pull requests. See If a large change times out.

3. Verify the apply

After the apply stage is green:

  1. Open the log of the apply step.
  2. Check that the requested change was carried out: the rule collection group, the collection or the IP group appears as added or changed.
  3. Do not rely on the green stage alone. If the change is not in the apply output, do not resolve the ticket. Investigate, and ask a second engineer if needed.
  4. Check in the portal that the rule is present, and test the traffic if the requester can help (Verify).

4. Run the pipeline for prod

Repeat step 2 for prod. The production plan waits for an approval of a second engineer. Check the plan again. Then follow the run, and verify the apply as in step 3.

5. Close the ticket

  1. Open the ticket of the request. The pull request links to it.
  2. Add a line to the discussion that says that the change is deployed, in which environments, and what the requester can test.
  3. Assign the ticket to the requester and move it to Resolved. The requester validates it and moves it to Done (The standard change process).

If it goes wrong

  • A pipeline error: read the log, fix the cause with a new pull request, and run again. A rule that is wrong in production is reverted with a pull request (Roll back).
  • Already exists after a time-out: import the existing group into the state. Do not destroy it in production (Common problems).