Capability restriction config for Lua #40626
Description
Title: Add capability restriction config for Lua pertaining to Envoy wrappers as well as Lua libs
Description:
This FR proposes the addition of a new field to the Lua filter config (similar to the CapabilityRestrictionConfig for Wasm) that can restrict access to the Envoy wrappers (e.g. httpCall) and the LuaJIT provided libs (with function level granular blocking). This becomes important when Envoy is used in a service mesh setting (e.g. Istio) where users can bypass the service mesh APIs to run custom scripts that could potentially affect mesh performance making it a debugging nightmare for managed offerings. With the addition of this field, managed services can intercept user intent to override the "allowed_capabilities" to block risky operations like network access, filesystem access, etc. and limit user configurability to tasks like mutating response/request headers. Another use case could be when Envoy is provided as a "safe runtime" for Lua.
Implementation Ideas:
To block the wrappers, we could just prevent the registration of the non-allowed types here and this should be isolated since this is done per filter config.
For blocking Lua libs and functions, we could selectively open the libs instead of opening all which is as per the Lua manual (https://www.lua.org/manual/5.1/manual.html#5)
To have access to these libraries, the C host program should call the luaL_openlibs function, which opens all standard libraries. Alternatively, it can open them individually by calling luaopen_base (for the basic library),...
Individual functions can be blocked using the Lua C APIs
// Blocking `math.abs()`
lua_getglobal(L, "math");
lua_pushnil(L);
lua_setfield(L, -2, "abs");
lua_pop(L, 1);
Would appreciate some feedback on the use case and the proposed implementation. If this looks good directionally, I can send out a PR soon. Thanks!