Envoy: Add ability to execute Filters over gRPC to mutate payload.

[PiotrSikora]

Add ability to execute Filters over gRPC to mutate payload.

This issue is pretty much just a placeholder for a discussion and to gauge the interest in the community for such feature, no indent to work on it anything soon.

[mattklein123]

@PiotrSikora is the intention here to make core changes, or to just have a filter that calls out to a gRPC service for each potential hook point? If the latter, makes a lot of sense to me.

[PiotrSikora]

The latter :)

[stale[bot]]

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 other activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[venilnoronha]

Not stale.

[htuch]

Reopened due to interest from @venilnoronha. I think a good first step here would be to define a gRPC proto API for this.

[stale[bot]]

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 other activity occurs. Thank you for your contributions.

[brectanus-sigsci]

I am interested in this as well for HTTP inspection and am happy to help out where I can.

I would like to see the full request and response data via gRPC calls similar to what I can get today by utilizing both the ext_authz gRPC for request combined with http_grpc_access_log for the response data. While this works for my needs now, it is a bit limiting, feels a bit hackish and is a bit cumbersome to configure.

It would be nice to be able to have a generic filter that receives both request and response data, blocks the request processing like ext_authz with a timeout and allows calling gRPC with the request data and again with the response data. Something similar to the tap filter, but with (optionally?) blocking calls to gRPC for each direction is ideal for my needs. The ability to mutate is a bonus.

[brectanus-sigsci]

@htuch Any further discussion/thoughts on getting started on this? Anything I can help out with in the immediate?

[htuch]

@brectanus-sigsci we've not had any bandwidth to tackle this one. I think if you want to work on this we'd be happy to help do design and code review. I think a brief design doc would be a good start if you are up for that.

[dio]

I think a good first step here would be to define a gRPC proto API for this.

@htuch Basically this is a generalization of ext_authz, but without doing any local response?

[htuch]

@dio I think in its most general form, all the filter operations, e.g. for HTTP the decode and encode, headers/body/trailers, could be offloaded as desired to some remote gRPC endpoint. If we can define an API for this that accommodates this, I think we could start with something closer to ext_authz, which might just do decodeHeaders for MVP and then expand out the set of ops. It's up to whoever builds it I reckon, but the important thing is to define the API clearly for the general case.