Feature Request: JSON-RPC support

[riptl]

Title: JSON-RPC over HTTP support

Description:

JSON-RPC is a light-weight, transport-agnostic remote procedure call (RPC) protocol. The most common transport protocols are HTTP and WebSockets, and sometimes TCP and Unix domain sockets.

JSON-RPC is commonly used to provide remote access to management interfaces. It is particularly prevalent with cryptocurrency P2P clients, being the primary access method for the majority of projects.

A common use-case of an Envoy JSON-RPC filter is access control. For example, the ext_authz module could be used to limit access to harmless read-only methods to lesser privileged users, while allowing admins full control.

Relevant Links:

Specifications:

• JSON-RPC 1.0 Specification: https://www.jsonrpc.org/specification_v1
• JSON-RPC 2.0 Specification: https://www.jsonrpc.org/specification

Notable users:

• Ethereum clients: https://eth.wiki/json-rpc/API (Cloudflare: https://blog.cloudflare.com/cloudflare-ethereum-gateway/)
• Bitcoin Core: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
• Facebook's Diem: https://github.com/diem/diem/blob/master/json-rpc/json-rpc-spec.md
• Deluge Torrent Client: https://deluge.readthedocs.io/en/latest/devguide/how-to/curl-jsonrpc.html

[snowp]

Seems fine to me if someone is willing to do the work and a maintainer wants to sponsor the extension, I imagine this would just be a fairly simple HTTP filter that parses the request/response to set some dynamic metadata for use with ext authz or RBAC.

Marking as help wanted, though let me know if you're interested in tackling this.

[storyicon]

I encountered the same problem and am interested in developing the filter for this, but before that, I think we need to reach a consensus on the design. For example, how to influence the routing of a JSON-RPC request based on its method. @terorie @snowp Any further ideas we can discuss here.

[storyicon]

It seems that if we don’t add a field for JSON RPC like gRPC, we have to pass DynamicMetadata []*v32.MetadataMatcher: https://github.com/envoyproxy/go-control-plane/blame/e7fb5d0c57d215361beab460b34a238d55f627dd/envoy/config/route/v3/route_components.pb.go#L1083

[riptl]

Let me share a few random bits of information that might help with making a decision. I have contributed to a JSON-RPC API gateway solution in a SaaS company. We see a fair amount of traffic with a few thousand upstreams to ~20 JSON-RPC APIs written by third parties. Our existing system is based on OpenResty, and we are interested in migrating to Envoy to seek to improve performance and observability.

• Some upstreams speak versions of JSON-RPC that aren't compliant with the latest standard, and unfortunately software in the wild depends on this behavior. The standard mandates that the client sends "jsonrpc":"2.0" in the request object, however some clients don't do this. This brings up the question how closely Envoy would want to follow the JSON-RPC 2.0 spec in general. Spec violations are getting rarer though.
• So far all ways of doing auth I've seen are at the HTTP layer, and can be achieved with the existing Envoy functionality.
• JSON-RPC is widely used with blockchain node implementations and their (financial) data APIs, which are usually monoliths, i.e. upstreams are able to answer requests of all methods.
• JSON-RPC upstreams usually serve APIs with control-plane functionality for trusted downstream clients. Specific to blockchain, we add (a lot of) checks in the API gateway to allow untrusted downstreams, like filtering disruptive request methods and parameters. Filters range from simple "method allow lists" to arbitrary validation rules on the JSON content in the params field, e.g. "make sure the number of items being requested is below X".
• Routing decisions are usually made based on the range of information (block height) being requested. This takes on arbitrary places in the params part of the request. I don't know whether it's practical to export the entire params field to dynamic metadata, since it can get quite large (few KBs).
• JSON-RPC 2.0 does not mandate the use of HTTP (or any protocol for that matter). IMHO we should try to split the structure potential Envoy JSON-RPC implementation into transport-agnostic and transport-specific (HTTP, WebSocket) functionality. This would allow the use of JSON-RPC over Unix sockets in the future should we need it.
• JSON-RPC over WebSockets introduces unexpected complexity through server-to-client requests (used for delivery of asynchronous subscription events). This makes the transport stateful, thus preventing Envoy from multiplexing multiple downstream WebSockets into a single upstream WebSocket.
• JSON-RPC batches are especially annoying to deal with. They allow clients to bundle together lots of unrelated requests in a single request handling path, potentially causing routing conflicts (messages within a batch trying to take different routes). When the server tries to block the entire batch, the only spec-compliant way of sending an error response is repeating that error for every single batch request. This is so stupid that practically no vendor implements it this way, and instead responds with a standalone JSON-RPC error response to a rejected batch request.

I hope this wasn't too verbose and is useful for anyone trying to implement this feature.

A first suggestion on the design

• Provide one filter class: JSON-RPC over HTTP, with the option to enable WebSocket support.
• RPC method block/allowlists built in directly into the filter
• Debug functionality to log RPC requests and responses
• Maybe JSONPath / jq-like syntax to pick arbitrary request data for dynamic metadata? Not sure how this would look with batches though