Add support for with_request_body in SecurityPolicy.spec.extAuth

[mjf-89]

Envoy supports sending the full request body to the external authorization server via the with_request_body filter configuration. Do you think that it is possible to expose such feature on the SecurityPolicy.spec.extAuth api?

My use case specifically relates to LLM model serving with an OpenAI compatible server. There you receive a request JSON body with a model field. I would like to have an opa-envoy authz server that is able to authorize requests based on the user identity and the model requested.

Relevant Links:

• https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter#configuration-examples

[zirain]

cc @zhaohuabing

[zhaohuabing]

@mjf-89 I think this is a reasonable request and should be a fairly simple change. Would you like to take a shot at implementing it, or waiting for someone from the community to pick it up?

[arkodg]

Can't this be solved with ext proc?

[mjf-89]

@zhaohuabing I can take a shot at it, this is my first time so I'll probably need some pointers in case I'm lost. Where should I seek help? On the slack channel?

@arkodg my use case can be definitively solved with an extproc but that would require writing a custom extproc dealing with opa which would not be needed with the extauth protocol. Indeed OPA already provides a grpc server that implement the extauth protocol: https://www.openpolicyagent.org/docs/latest/envoy-introduction/

[zhaohuabing]

I can take a shot at it, this is my first time so I'll probably need some pointers in case I'm lost. Where should I seek help? On the slack channel?

If we agreed on the extAuth approach, you can start by creating an API PR first, then a follow-up PR for Gateway API translation, xDS translation, and tests. The frameworks of translations are already in place, so the modification should be straightforward.

API: https://github.com/envoyproxy/gateway/blob/main/api/v1alpha1/ext_auth_types.go
Gateway API translation:

gateway/internal/gatewayapi/securitypolicy.go

Line 808 in 8f0131c

func (t *Translator) buildExtAuth(policy *egv1a1.SecurityPolicy, resources *resource.Resources, envoyProxy *egv1a1.EnvoyProxy) (*ir.ExtAuth, error) {

xDS translation:

gateway/internal/xds/translator/extauth.go

Line 97 in 8f0131c

func extAuthConfig(extAuth *ir.ExtAuth) *extauthv3.ExtAuthz {

[arkodg]

@mjf-89 my suggestion would be to use an ext proc server https://gateway.envoyproxy.io/docs/tasks/extensibility/ext-proc/ for message transformation and enriching a header based on the body which can be used along side another ext authz server like opa, this is temporary and can be removed once this is supported natively envoyproxy/envoy#35783

[mjf-89]

@arkodg thanks, that indeed seems a very good suggestion, I definitely misunderstood your first comment.

However I have to say that design-wise I don't see the point of not exposing all the configuration options of the extensions.filters.http.ext_authz.v3.ExtAuthz proxy api to the gateway via the SecurityPolicy.spec.extAuth.

Is there any reason to keep the SecurityPolicy.spec.extAuth so dry?

[arkodg]

there's a short term cost to developing this as well as a long term cost to maintaining it as well as additional complexity it adds to the project. This also makes documentation complex since the project will now need to explain the pros/cons of providing two ways to solve the same use case.

Having said this, if there's a subset of users, who are migrating to Envoy Gateway and have already implemented the functionality in ext auth, it does make sense to add native support for it . Lets keep this issue open and see if others face the same issue

The current workarounds are

• Implement body inspection functionality using ext proc https://gateway.envoyproxy.io/docs/tasks/extensibility/ext-proc/
• Use EnvoyPatchPolicy to enable with_request_body https://gateway.envoyproxy.io/docs/tasks/extensibility/envoy-patch-policy/

[glachac-safelishare]

+1 on this issue. I'm hitting the same thing. I have opa policies that need to have the body to work with.

Is there an example of using the EnvoyPatchPolicy to workaround this?

[jonbk]

We are currently blocked due to the lack of a feature to verify a signature placed in the request body against an external gRPC authentication server. The proposed workarounds don't seem viable for production use, as noted in the documentation.

The ability to handle such signature verification appears to be a critical requirement for many use cases, including ours. I don’t understand the reluctance to implement this functionality, which seems essential.

Thank you for your attention to this matter.