Firewall Rule Organisation¶
How to organise the firewall rule files so that every rule can be traced to a workload, conflicts are rare and a decommissioned workload takes its rules with it. This page gives the design reasoning and the file structure. The details of naming, priorities, IP groups, limits and safe changes are in Firewall rule and IP group guidelines. The file format and the procedure are in Firewall rules.
The problem¶
Rules that are organised by technology (for example one collection AllowDatabase per region) become hard to manage as
workloads are added:
- you cannot tell which rules belong to which workload,
- rules overlap or conflict across workloads,
- when a workload is decommissioned, nobody knows which rules to remove,
- the extra dimension of regions makes it worse.
Guidance: organise by workload¶
Group rules around the workload and its purpose, not around a technology. These kinds of files cover everything:
| Kind of file | Contents | Where |
|---|---|---|
| Platform infrastructure rules | Only the core rules the platform team manages: operating system updates, basic monitoring, platform diagnostics, DNS, build agents. See Platform base rules. | Global folder, one file |
| Functional requirement files | One file per functional requirement that applies to many workloads. Each maps to one design decision, for example standard ports for private endpoints in dev and test, or build agent access. | Global folder, named after the requirement |
| Regional common rules | Rules that are specific to one region and apply across several workloads. Keep these to cases with a real regional difference. | Region folder, with the region in the file name |
| Workload files | All rules of one workload. All environments (dev, tst, acc, prd) are separate rule collections in the same file, with a standard collection name that includes the environment. | Global folder, or the region folder when a regional difference is real (failover, data residency) |
Name rules so they show the traffic flow and the reason, for example <action><workload>_<reason>_<environment>
(AllowApp1_FromJumpHost_ToDb_tst), and keep the environment in the name of the collection.
Global and regional files¶
In MCP the global and the regional files are merged, and a regional file with the same file name as a global file replaces it in that region (Firewall rules). Put the region in the name of region-specific files so they cannot shadow a global file by accident, and use the replacement only on purpose.
Consistency across regions¶
When regions back each other up (for example with an active/standby connection to on-premises), the same rules should exist in both. A failover then does not fail on a rule that exists in one region only. Differences between regions need a reason. This costs a review step when rules are added, but it removes a class of failover problems.
Priorities¶
Reserve a range of rule collection group priorities per kind of file, so that two teams never need the same number. An example, following the file kinds above:
| Range | Use |
|---|---|
| 100 - 199 | Platform infrastructure rules |
| 200 - 299 | Global functional requirement files |
| 300 - 499 | Regional common rules |
| 500 - 5000 | Workload files, with a block per workload |
A second scheme in use splits workloads into production and non-production ranges, with a block per workload
(example scheme). Choose one, write it down and leave gaps. Do not use priority
8999, which the platform reserves.
Rules at the destination¶
Put a rule in the file of the destination workload and describe incoming traffic (on-premises and the internet are the exceptions: they have no workload file). The firewall is shared. If workload B could add a rule that lets B reach workload A, then A would be reachable without A's approval, and the evaluation order would decide who wins. With rules at the destination, A decides who may enter. How requests are divided is in How to request.
Platform base rules¶
The platform team owns a global rule set that all workloads depend on. It typically contains:
| Category | Examples |
|---|---|
| Name resolution and directory | DNS to on-premises servers, directory service ports |
| Updates | Operating system update services, update FQDN tags, automation endpoints |
| Monitoring | Azure Monitor and Application Insights endpoints, diagnostics |
| Time | Time synchronisation |
| Pipelines | Endpoints that hosted and self-hosted agents need (source code hosts, package registries, tool downloads) |
| Management | Bastion to SSH and RDP in the workload ranges |
Keep these apart from workload files, so a workload's removal never touches them.
Letting workload teams propose changes¶
Teams can get read access to the firewall rule repository, so they can see which rules apply to them and whether the firewall is the cause of a problem. They can also be allowed to open pull requests for their own workload's file. This shortens the lead time: a pull request is easier to validate than the text of a ticket that someone has to interpret.
Keep these conditions:
- the platform team (and, where your process requires it, the security officer) still approves and deploys,
- the ticket or change record stays mandatory,
- pull requests are allowed per team, after the team has shown that it knows the rules, Git and the firewall.
See Pull request review for what the reviewer checks.
Consequences¶
Positive:
- a clear link between rules and workloads,
- easier troubleshooting when connectivity fails,
- an easy decommissioning process: delete the workload's file,
- fewer orphaned rules,
- consistent naming and fewer priority conflicts.
Negative or to watch:
- every regional rule needs a justification,
- region-specific addresses and resources are harder to handle,
- keeping the regions consistent needs an extra review,
- the structure only holds if the team keeps to it as the platform grows.