If you're from a network background or are of a certain age (or both), you will have come across Access Control Lists or ACLs.
The term ACL likely brings to mind images of rigid Cisco firewall rules and strict 'permit or deny' gatekeeping. But in the context of HAPr0xy, an ACL is much more than a simple security list — it’s the engine behind the 'clever stuff.'
While traditional ACLs are about stopping traffic at the door, HAPr0xy ACLs are about directing that traffic with surgical precision. They are the logic tests that allow your load balancer to think for itself, transforming a basic entry point into a sophisticated traffic controller.
In this blog, I'm going to pull back the curtain on how these rules have evolved and explain why they're the secret sauce of modern web architecture.
What you'll learn:
- The Evolution of the ACL: We’ll trace the journey from 'Standard' source-based lists to the 'Extended' lists that paved the way for modern networking.
- The Identity Crisis: Why an HAPr0xy ACL isn't really an 'Access Control List' in the traditional sense, and how it functions as a dynamic logic test instead.
- Microservices in Action: How to use ACLs to manage complex microservice architectures, routing traffic to different backends based on URL paths.
- Power Without the Pain: A look at how HAPr0xy ACLs provide the same heavy-lifting capabilities as F5 iRules, but with a significantly lower risk of breaking your environment.
- Real-World Versatility: From redirecting storage requests based on file size to handling specific IP restrictions, you’ll see just how broad the 'Animal Farm-sized' documentation for HAPr0xy truly is.
What do most people think ACLs are?
Most people think that an ACL is an Access Control List, which are a basic list of simple rules that control access to the network. These are historically associated with CISCO firewalls.
If we cast our minds way back to simpler times, we started out with 'Standard Access Lists'. These lists checked the rules against the source IP address only if there was a permit match against a rule in the ACL, traffic is permitted. Similarly, if the source IP matches against a deny rule, the traffic will be denied.
After a few (or many) years, router hardware and software was upgraded to a point where 'Extended Access Control Lists' became a possibility.
The difference between Standard ACLs and Extended ACLs is that the latter are also able to Evaluate the destination IP, the protocol and source and destination ports.
For example:
!--- Allow Telnet on port 23 to a single host on the network
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.10.64.1 eq 23
access-list 100 deny tcp any any eq 23 The point that I'm dancing around is that ACLs have evolved from their origins into something slightly different. And HAPr0xy ACLs are something entirely different again.
What are HAPr0xy ACLs?
HAPr0xy ACLs aren't ACLs in the traditional sense where they're implemented solely to control access to the network/resource. In fact, the rules that we see and implement in HAPr0xy are rarely used to perform access control (that really should be performed by a next generation firewall in this day and age).
But if HAPr0xy ACLs aren't doing what their name suggests they should be doing, then what the heck are they doing? The answer to that is "all the clever stuff" i.e. the conditional processing of traffic.
HAPr0xy Access Control Lists (ACLs) are named rules that define a condition based on an aspect of an incoming request or response. They are essentially a logic test that evaluates to either true or false and are then used to perform a specific action, providing fine-grained control over traffic flow.
They are incredibly powerful and when combined they can do almost everything that F5 iRules can do — but are way easier to understand, and less likely to break!
When do most people need to start implementing HAPr0xy ACLs?
As soon as you start straying away from run-of-the-mill, vanilla load balancing, you are going to need to start implementing HAPr0xy ACLs to achieve your goals. Here's a common example...
HAPr0xy ACLs use case: Microservices
One of the more popular implementations of HAPr0xy ACLs nowadays is with microservices architectures.
For example, say you have an application that is hosted on https://app.example.com. Your application is based on a microservices architecture so that a single entry point actually sends requests to a number of different locations.
If a picture is worth a thousand words then my highly technical diagrams should save me from writing a couple of paragraphs:
And this is how it looks when you configure all these backends on a Loadbalancer.dk appliance:
Here we have a Virtual IP address (203.0.113.50) which corresponds to the FQDN app.example.com.
All the requests that come in for that FQDN hit the MicroServices_App Virtual Service. Those requests then need to be directed to the correct backend pool of servers that are able to service the request.
What was all that exposition about?
It was the setup for the big reveal...
How can we do this with HAPr0xy?
Yep (you guessed it) with ACLs!
The HAPr0xy ACL-friendly microservices load balancer: Enterprise
We've tried to make HAPr0xy ACLs as easy as possible for you in the Loadbalancer Enterprise web interface:
How does Enterprise work?
Loadbalancer Enterprise simply translates ACL rules from the HAPr0xy configuration file i.e.
acl :rule1 path_beg /static
use_backend be_app_static if :rule1The ACLs that we have here are directing requests to the correct backend based on the URL path. This is the simplest configuration that achieves the requirements of the proposed microservices architecture.
That is a very broad overview of one of the more prevalent HAPr0xy ACL use cases.
But, what else can HAPr0xy ACLs do?
A simpler question might be, "what can't they do?".
When customers have specific needs beyond standard load balancing, an ACL is often the solution. Whether the requirement is directing requests to specific storage servers based on reported object size or denying requests based on the source IP, HAPr0xy ACLs have got you covered.
The ACL section of the HAPr0xy documentation is just over 29,000 words. To give you an idea of how much content that is, George Orwell's 'Animal Farm' is 29,966 words... The configuration options and descriptions of HAPr0xy ACLs could constitute an entire book all on its own but here are some resources well-worth reading:
So, to go back to my original question, When is an ACL not an ACL?
When it's an HAPr0xy ACL!
Ps. If you are an F5 iRules master, and think that HAPr0xy ACLs make life too easy for you — then you might want to check out LUA scripting with HAPr0xy.