On 2023-10-08 (So.) 14:15, Tristan wrote:
Since this was brought up,

On 7 Oct 2023, at 14:34, Willy Tarreau <w...@1wt.eu> wrote:

[…]

Maybe this will then bring up SPOE to a level where the body of a request
can be scanned and bring it to a full WAF level or as WASM filter.

Any thoughts on the feasibility of a WASM based alternative to the current LUA
platform?

From what I looked there are a few WASM runtimes set up for being embedded in C
applications, though I’m not expert enough on the tradeoffs of each to know if
there are dealbreakers.

I also realize that a lot of work went into the current LUA support (a long at 
the
frighteningly long .c file for it speaks volumes).

But on one hand I find it rather difficult to use correctly in its current 
state,
in part because of the complete absence (to my knowledge) of something 
equivalent
to C headers for validation ahead of deployment, and also in part (and more
personally) because I never understood what anyone could possibly like about LUA
itself…

There are at least 2 issues about the topic WASM and body handling of SPOE.
https://github.com/haproxy/haproxy/issues/1482
https://github.com/haproxy/haproxy/issues/913

From my point of view would it be very helpful when SPOE could handle
the body, but I think this is a huge change as there should also be some
protection about internal DoS for that topic. The benefit would be that
such a feature could open more languages within WASM context with all
there pro and cons.


[…]

Are there any plans to have something similar to XDS (
https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol ) for
dynamic configs at runtime, similar to the socket api and Data Plane API?

I used to have such plans a long time ago and even participated to a
few udpapi meetings. But at this point I think it's not haproxy's job
to perform service discovery

And that’s a very fair point. I wonder however how feasible it will 
realistically
be from dpapi’s perspective to add that to its remit.

That said I’d definitely be very interested as well. As much as handcrafted
configurations are nice, one quickly reaches their maintainability limits. And 
if
we’re to stop abusing DNS again and again, proper service discovery is the way.

I think that the DNS Stuff should be keep there and maybe be enhanced as
it looks to me some new Securtiy Topics are using DNS more and more like
ESNI, ECH, SVB, ...

Jm2c

Tristan

Regards
Alex

Reply via email to