Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for with_request_body in SecurityPolicy.spec.extAuth #4431

Open
mjf-89 opened this issue Oct 13, 2024 · 10 comments
Open

Add support for with_request_body in SecurityPolicy.spec.extAuth #4431

mjf-89 opened this issue Oct 13, 2024 · 10 comments
Labels
area/api API-related issues kind/enhancement New feature or request

Comments

@mjf-89
Copy link

mjf-89 commented Oct 13, 2024

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:

@mjf-89 mjf-89 added the triage label Oct 13, 2024
@zirain
Copy link
Contributor

zirain commented Oct 13, 2024

cc @zhaohuabing

@zhaohuabing zhaohuabing added area/api API-related issues kind/enhancement New feature or request good first issue Good for newcomers and removed triage labels Oct 15, 2024
@zhaohuabing
Copy link
Member

@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
Copy link
Contributor

arkodg commented Oct 15, 2024

Can't this be solved with ext proc?

@mjf-89
Copy link
Author

mjf-89 commented Oct 15, 2024

@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
Copy link
Member

zhaohuabing commented Oct 15, 2024

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:

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

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

@arkodg
Copy link
Contributor

arkodg commented Oct 15, 2024

@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
Copy link
Author

mjf-89 commented Oct 16, 2024

@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 arkodg removed the good first issue Good for newcomers label Oct 18, 2024
@arkodg
Copy link
Contributor

arkodg commented Oct 18, 2024

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

@glachac-safelishare
Copy link

+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
Copy link

jonbk commented Oct 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api API-related issues kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants