On Wed, May 21, 2025 at 01:15:30PM +0200, Maximilian Moehl wrote:
> > > > > > So far, it seems like the only options would be custom LUA or SPOE.
> > > > >
> > > > > I see two options :-) .
> > > > >
> > > > > Runtime API directly
> > > > > https://www.haproxy.com/blog/dynamic-configuration-haproxy-runtime-api
> > > > > or
> > > > > Dataplane API https://github.com/haproxytech/dataplaneapi
> > > >
> > > > I'm aware of the runtime API, but I don't see how I can add new ACL
> > > > lists or
> > > > remove existing ones and dynamically reference them in `tcp-session`
> > > > rules,
> > > > can you please explain how I could achieve something like this? Maybe
> > > > I'm just
> > > > missing some detail.
> > >
> > > There are examples in the blog post.
> > > https://www.haproxy.com/blog/dynamic-configuration-haproxy-runtime-api#updating-acls
> > >
> > > and in that one
> > > https://www.haproxy.com/blog/introduction-to-haproxy-acls#using-the-runtime-api
> > >
> > > For example.
> > >
> > > ```
> > > echo "add acl /etc/hapee-1.8/whitelist.acl 1.2.3.4" | socat stdio
> > > /var/run/hapee-lb.sock
> > >
> > > ```
> > > The documentation for the commands are in the managment guide
> > > https://docs.haproxy.org/3.1/management.html#9.3-add%20acl
> > > https://docs.haproxy.org/3.1/management.html#9.3-add%20map
> >
> > Adding new lists or files dynamically is unfortunately not supported. It's
> > not
> > possible to modify a TCP rule over the CLI.
>
> That was my understanding as well. Thank you for confirming it!
>
> If you have other suggestions on how to achieve this besides LUA and SPOE,
> please let me know.
What is important to understand is that the entirety of the files you
are going to use at run time must be known during parsing and will be
loaded. So by definition there's no such notion as determining the name
of a file and loading it on the fly during traffic processing. And that
would be terrible for performance (not even speaking about security when
the file name is determined from traffic).
I have no idea how many such different files you need, but if it's a low
number, say 10, you can very well combine multiple ACLs in your rules.
For example:
tcp-request session set-var(sess.allowlist)
ssl_fc_sni,map(/usr/local/etc/custom_allowlists)
tcp-request session accept if { var(sess.allowlist) -m str 1 } { src -f
/path/to/list1.acl }
tcp-request session accept if { var(sess.allowlist) -m str 2 } { src -f
/path/to/list2.acl }
tcp-request session accept if { var(sess.allowlist) -m str 3 } { src -f
/path/to/list3.acl }
tcp-request session accept if { var(sess.allowlist) -m str 4 } { src -f
/path/to/list4.acl }
This remains very cheap as a single ACL will be evaluated (at most),
the rest being only a single variable. In certain cases, depending on
your architecture, this can even be deferred to backends, in which
case only one rule will be evaluated. This can ease the setup when
dealing with multiple rules, but it depends if your server farm is
compatible with such an architecture:
frontend
tcp-request session set-var(sess.allowlist)
ssl_fc_sni,map(/usr/local/etc/custom_allowlists)
use_backend back-%[var(sess.allowlist)]
back-1
tcp-request session accept if { src -f /path/to/list1.acl }
server ...
back-2
tcp-request session accept if { src -f /path/to/list2.acl }
server ...
...
Willy
