Open emike922 opened 3 years ago
cc @dio
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
Still interested
I'm also interested in this! Especially because lua filters are advertised as filters, passing the filter if there is an error in the lua program seems like a very dangerous default to me.
@emike922 Should the default state return 503 or 500? While it could be argued the service is unavailable (ie it's broke) is a fair assessment and maybe a 503 error would make better sense from a security perspective but it seems to contradict the 500 error.
It is likely safer to fail/close on default, I suspect this might break some existing installations but it does provide more safety.
@twghu I think we should aim to emulate the Wasm filter, which does a similar thing based on its fail_open
setting:
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/wasm/v3/wasm.proto#extensions-wasm-v3-pluginconfig
@emike922 ack, good call.
@twghu are you going to raise a PR on this? Either API or runtime guard seems fine. But yeah I agree this should be fail/close on by default for now (however, runtime guard promotes running the new behavior by default (if the new behavior is "fail/open") so be careful when introducing this as a breaking change).
Is there a way to run Lua filters as "fail closed"? I have observed that the requested resources are served normally if an error/exception occurs in the Lua script. I would rather see 503 (at least for some scripts, s.a. a Lua auth filter). Can this be done/configured, or do I need to be super defensive (paranoid) when writing the filter?