Authorization Policy based on fields in request body

[senthilrch]

Describe the feature request
The "AuthorizationPolicy" API provided by Istio supports defining authorization rules based on various attributes of the request: path, principal, requestprincipal, source, host, port, request header etc..This works fine for several scenarios.

Recently we have hit several scenarios in our project requiring us to define authorization rules based on json fields in the http request body. Within our project we use several micro services (both in-house and third party components) that expose resources that can be accessed only via fields in the request body. These are resources that cannot be represented in the API path.

I request you to consider adding support for "fields in the request body of the http request" in the AutorizationPolicy API in upcoming releases.

Describe alternatives you've considered
I've considered the following alternatives to work around this limitation.

1. opa-envoy-plugin:-
As part of the Open Policy Agent project, this plugin supports defining fine-grained policies using a policy language. There is support for defining policies based on fields in the request body. The opa container should be run as a sidecar within the Pod. It installs a ext_authz filter into the envoy proxy sidecar. The policies then get enforced within the opa container. For more details, refer to following URL:-
https://github.com/open-policy-agent/opa-envoy-plugin#example-policy

The following screenshot depicts how OPA policy is defined to read the fields in the request body:-

This approach doesn't scales well and introduces new friction within the team to learn and use an additional policy language outside of Istio. The need to run additional opa side car and the ext_authz hop to it, introduces latency.

2. Lua filter:-
The second alternative is to use Envoy's LUA filter to write LUA code to read the request body. Something on the lines of the following (thanks to chen for sharing it: https://discuss.istio.io/u/chen)

This approach has the advantage of being Istio-native, however it becomes unwieldy when the Auth policy rules have to be based on both request body and other attributes in the http request. This also requires developers to learn LUA and keep maintaining the LUA code.

[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Additional context
https://discuss.istio.io/t/istio-auth-policy-based-on-fields-in-request-body/8991/2

[yangminzhu]

Note, this means the rbac filter will need to buffer the request body which is not supported today.

Do you need any custom parsing of the body? I'm not sure if a simple text matching would be useful enough here, it seems in most cases you will want a more semantic matching?

[senthilrch]

Checked the list of HTTP filters supported by Envoy proxy in the data plane:-
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters

None of the filters have capability to read the request body (The RBAC filter has no support for defining policy rules based on contents of the request body.). Perhaps the only way out is to install a LUA filter (stable) or hook in a wasm plugin using the wasm filter (experimental)?

From: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2020-11-25. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

[senthilrch]

@leefernandes the reference you've provided is to add support for sending the request body to the ext_auth server and performing some checks when forwarding the request to the ext_auth server.

This issue is about adding support for request body in the AuthZ checks performed by Istio. Nevertheless this issue cannot be fixed in Istio because Envoy's in-built filters do not support it.