add gRPC client builtins

[srenatus]

We've got builtins to query HTTP endpoints, and we're tracking an enhancement for LDAP querying in #938. What about gRPC? It's not HTTP-compatible enough to be comfortably queried using http.send.

Commonly, you'd generate your gRPC client code from the proto3 service definition. However, if you look at how grpcurl does it, cleverly using github.com/jhump/protoreflect to fetch the service's definition at runtime using the reflection API -- OPA could do the same, and make it available via an interface not too different from http.send.

It could look like grpc.send({method, host, message, metadata, output}) (metadata is just headers in grpc-land). The marshaling and unmarshaling of the input and output messages could be done via JSON, just like grpcurl does it.

output := grpc.send({"method": "chef.automate.domain.authz.v2.Policies/ListPolicies", "host": "your-grpc-server", "message": {}, "headers": {"X-Foo":"bar", "X-Opa": "rules"}})

Note that gRPC defaults to using TLS, so the recent improvements to http.send TLS support (#1067) would be relevant here, too.

Caveats

• I just think this would be a neat feature, but have no current urgent need myself. 😅
• It's probably dependency-heavy, grpcurl pulls in protobuf, grpc, etc..

[tsandall]

I agree this would be useful, I'm just hesitant about including dependencies for N different protocols. Labeling this as "design" so that we can track it and keep it in mind.

[jpeach]

I'd also be able to make use of GRPC builtins.

One option might be to expose additional builtins as separate Go modules. Then a runtime that uses the core OPA engine can add them if it makes sense and the dependencies are not dragged into the main module. The obvious downside of this is the increased release management overhead :)

[srenatus]

✨ maybe via #3631, one day. 🌠

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.