Enable GRPC Connectivity for Ratelimit

[jswinner09]

Gloo Edge Product

Open Source

Gloo Edge Version

1.13x

Is your feature request related to a problem? Please describe.

While trying to migrate the ratelimit component to a new openshift environment the status is showing as healthy but it is failing to accept any new requests and throwing grpc connection errors. Currently you are not able to enable grpc connectivity for ratelimit with an authority header in Gloo like you can for ExtAuth.

Describe the solution you'd like

Provide a dev build or release where RL gRPC service exposes Auth header rewrite similar to ExtAuth.

Describe alternatives you've considered

exclude the Istio sidecar from the proxy

Additional Context

No response

[soloio-bot]

Zendesk ticket #3027 has been linked to this issue.

[soloio-bot]

Zendesk ticket #2795 has been linked to this issue.

[sam-heilbron]

We set the Authority on the ExtAuth Filter here: https://github.com/solo-io/gloo/blob/main/projects/gloo/pkg/plugins/extauth/config_generator.go#L250. This was introduced as part of solo-io#5738 so @asayah and @bewebi would be good people to go to for context on the changes.

The RateLimit filter code can be found here: https://github.com/solo-io/gloo/blob/main/projects/gloo/pkg/plugins/ratelimit/util.go#L21. We do not yet set the Authority header anywhere, and if we want to configure it, we would need to set it in the API.

Per the GrpcService spec: https://github.com/solo-io/gloo/blob/main/projects/gloo/api/external/envoy/config/core/v3/grpc_service.proto#L28

// The ``:authority`` header in the grpc request. If this field is not set, the authority header value will be ``cluster_name``.
// Note that this authority does not override the SNI. The SNI is provided by the transport socket of the cluster.

Given that we already supply the cluster_name, why is that value not sufficient for the current requirements?

[sam-heilbron]

@jswinner09 The request is to Provide a dev build or release where RL gRPC service exposes Auth header rewrite similar to ExtAuth.. What version of Gloo Edge should this dev build be based off of?

UPDATE: Per Slack convo the initial dev build with target the 1.13 version.

[nrjpoddar]

Given that we already supply the cluster_name, why is that value not sufficient for the current requirements? - because when the Istio proxy sidecar is injected in Edge proxy pod you need the authority to be set to the Ratelimit K8s service name for routing to work correctly. Like you said that right now we default to cluster name which breaks the routing via sidecar proxy.

[sam-heilbron]

Given that the upstream service we are communicating with, may be fronted by a Proxy, this change makes sense, and I think there is value in consistency between the options we expose for our RateLimit and ExtAuth integrations.

I would recommend that we solve this by mirroring the changes for the ExtAuth filter: solo-io#8995 (comment)

Tangential to this solution, I am curious about because when the Istio proxy sidecar is injected in Edge proxy pod you need the authority to be set to the Ratelimit K8s service name for routing to work correctly. I may need the exact configuration that is being used to fully understand it, but I would have assumed that relying on an Istio passthrough cluster would be enough to support the requirement.

[jenshu]

Pausing this work and closing the PRs for now, as it's unclear if it will fully solve customer's issue

solo-io#9011
solo-io/solo-apis#1099
https://github.com/solo-io/solo-projects/pull/5621

[jenshu]

will be available in GlooEE v1.13.31, v1.14.15, v1.15.13, v1.16.2, v1.17.0-beta1