> > > > > > > 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 see, that makes sense.
> 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 ...
> ...
Unfortunately, we have a shared backend and will probably need more than a few
lists.
Thank you all for your help!
--
Max
