In this post, I will discuss how you can use Rules Collection Groups in Azure Firewall to aggregate your Rules Collections and Rules to be aligned with a service definition or workload definition.
Workload and Service Definitions
In an organised environment, every workload (or service) has a definition. That definition describes all of the components that make up and facilitate the workload. That includes your firewall rules.
So it would make sense if you had a way of grouping firewall rules together if those rules are used to make a workload possible. For example, if I was running an Azure Virtual Desktop pool, I might treat that pool as a workload, document it as a workload, and want all of the rules that make that pool possible to be grouped together and managed as a unit.
Challenges
The challenges I have faced with Azure Firewall and aligning rules along the model of a workload definition have been:
Realisation & Conceptualisation
I’ve always used some kind of workload-based approach but my approach wasn’t perfect. I decided to try to align rules with NSGs, placing inbound rules with the workload that was the destination. But then some workloads, such as Windows Admin Center or ADDS, require more reach, and then you get messy. And what if you have a dozen or more workloads that are atomic units but are also extremely integrated? Where do the rules go?
I’ve come to realise that rules should go with the service that they empower, regardless of destination. What made me think like that? Documentation of workloads for a forced-ad-hoc migration project that I’ve been working on for the last year. We didn’t get the chance to assess and plan in detail, so everything was an on-the-fly discovery. Our method of “place the rule with the target workload” has created very complicated ARM templates for Azure Firewall; defining a workload from a firewall perspective is very hard with that approach.
If we said that “all network rules that empower a workload go with the workload’s network Rules Collection” then things would get a bit better – a bit.
Rules Groups Collections Limitations
It is a year since Firewall Policy became generally available. Just like last year, I had some hours to experiment on Azure Firewall. I tried out the new tier, Rules Collection Groups. A reminder:
- Rules > Rules Collections (typed, based on DNAT, Network, or Application)
- Rules Collections > Rules Collection Groups
But at the time, the new tech was immature. Mixing Rules Collection types between Rules Groups was a disaster. The advice I got from the product group was “don’t do it, it’s not ready, stick with the default groups for now”.
So I did just that. That means that the DNAT rules collection, the Network Rules Collection, and the Application Rules Collection for any workload were split into 3 deployments, the default rules group collections for:
- DNAT
- Network
- Application
Each of those deployments could have dozens or hundreds of rules collections for each workload. And when you combine that with my previous approach to rules placement:
- It’s a mess
- Deploying a rule change required re-deploying all Rules Collections of a type for all workloads in using that type of Rules Collection.
A Better Approach
I have had some time to play and things are better.
Rules Alignment With Workload
I’ve discussed this already – place rules that empower a workload with the workload, not the destination workload.
If Workload X requires TCP 445 access to Workload Y, then I will create a Network Rule to Workload Y on TCP 445 in a Network Rules Collection for Workload X. The result is that all rules that make Workload X function will be in rules collections for Workload X. That makes documentation easier and makes the next step work.
Rules Collection Groups For Workload
This is the big change in Azure from this time last year. I can now create lots of Rules Collection Groups, each with a priority (for processing order). I will create 1 Rules Collection Group per workload. Workload X will get 1 Rules Collection Group.
All rules that make Workload X go into Rules Collection Groups for Workload X. I might have, depending on rules requirements, up to 6 Rules Collection Groups:
- DNAT-Allow-WorkloadX
- Network-Allow-WorkloadX
- Application-Allow-WorkloadX
- DNAT-Deny-WorkloadX
- Network-Deny-WorkloadX
- Application-Deny-WorkloadX
The Rules Collection Group is its own Deployment from an ARM perspective. If I’m managing the firewall as code (I do) then I can have 1 template (or parameters file) that defines the Rules Collection Group (and contained Rules Collections and Rules) for the entire workload and just the workload. Each workload will have its own template or parameter file. A change to a workload definition will affect 1 file only, and require 1 deployment only.
If you want to see an ARM template for deploying one of the workloads in my screenshot, then head on over to my GitHub.
Wrap Up
This approach should leave the firewall much better organised, easier to manage in smaller chunks if using infrastructure-as-code, be easier to document, and more suitable for organisations that like to create/maintain service definitions.