When is an ACL not an ACL? When it's an HAProxy ACL...

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 HAProxy, 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, HAProxy 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 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 HAProxy ACLs are something entirely different again.

What are HAProxy ACLs?

HAProxy 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 HAProxy are rarely used to perform access control (that really should be performed by a next generation firewall in this day and age).

But if HAProxy 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.

HAProxy 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 HAProxy ACLs?

As soon as you start straying away from run-of-the-mill, vanilla load balancing, you are going to need to start implementing HAProxy ACLs to achieve your goals. Here's a common example...

HAProxy ACLs use case: Microservices

One of the more popular implementations of HAProxy 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.org 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 HAProxy?
Yep (you guessed it) with ACLs!

The HAProxy ACL-friendly microservices load balancer: Enterprise

We've tried to make HAProxy 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 HAProxy configuration file i.e.

   acl :rule1 path_beg /static
   use_backend be_app_static if :rule1

The 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 HAProxy ACL use cases.

But, what else can HAProxy 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, HAProxy ACLs have got you covered.

The ACL section of the HAProxy 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 HAProxy ACLs could constitute an entire book all on its own but here are some resources well-worth reading:

• HAProxy config tutorials
• HAProxy ACL guide

So, to go back to my original question, When is an ACL not an ACL?

When it's an HAProxy ACL!

Ps. If you are an F5 iRules master, and think that HAProxy ACLs make life too easy for you — then you might want to check out LUA scripting with HAProxy.