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

New API for details on whether the request has taken DirectPath #11042

Open
surbhigarg92 opened this issue Mar 27, 2024 · 4 comments
Open

New API for details on whether the request has taken DirectPath #11042

surbhigarg92 opened this issue Mar 27, 2024 · 4 comments

Comments

@surbhigarg92
Copy link

Is your feature request related to a problem?

We want an easy/more consistent way to verify if a request has taken DirectPath or not.

Existing Solution

We are able to use ClientCall.getAttributes() method which is an experimental method to get the socket address like below
clientCall.getAttributes().get(Grpc.TRANSPORT_ATTR_REMOTE_ADDR)

So a client can say that it's connecting to a directpath endpoint if the IP address is within the subnet of 34.126.0.0/18 or
2001:4860:8040::/42

But the above way is difficult to maintains , comes with the burden of modifying this code if IP range changes.

Describe the solution you'd like

We would like to have a separate method to indicate if directPath is used, or a separate attribute indicating that.
clientCall.getAttributes().get(Grpc.**DIRECTPATH_USED**)

@ejona86
Copy link
Member

ejona86 commented Mar 27, 2024

Another option would be to check if TLS or ALTS was used. The attributes will have an SSLSession for TLS traffic. There is an attribute for ALTS, but it looks like ALTS doesn't expose it at all on client-side. Both io.grpc.alts.AuthorizationUtil and AltsContextUtil interact with it, but only on server-side. The simplest might be to extend AltsContextUtil with two additional methods for ClientCall. We can talk to the security team about that.

Another option may be to learn which cluster/locality the request was sent to. That isn't plumbed today, and wasn't planned on being exposed publicly soon, but we were going to plumbing this for use in metrics.

We could maybe have GoogleDefaultProtocolNegotiator add an additional transport attribute depending on whether it used TLS or ALTS. We'd need to create a handler to participate in the handshaking in order to add the attribute, as right now it decides earlier whether to use ALTS or TLS and then just delegates.

@sergiitk sergiitk added the Waiting on reporter there was a request for more information without a response or answer or advice has been provided label Mar 27, 2024
@temawi
Copy link
Contributor

temawi commented Apr 10, 2024

@surbhigarg92 Do the ideas Eric provided work for you?

@ejona86 ejona86 removed the Waiting on reporter there was a request for more information without a response or answer or advice has been provided label Apr 23, 2024
@surbhigarg92
Copy link
Author

Hi @temawi @ejona86 Sorry for the delayed response. Lost track of this ticket.

Yes, Eric's suggestion will works for us. Knowing that connection is using ALTS is enough to conclude we are using directpath.

So if grpc expose an attribute for ALTS on client side that would do it.

@ejona86
Copy link
Member

ejona86 commented Apr 29, 2024

Discussion from Friday:

  • Using IP subnet is stable, as the IPv6 subnet is configured in firewall rules
  • Seems AltsContextUtil should be available on client-side
  • Don't want to go too deeply down these paths, as auto fallback to non-DP needs to go away long-term (to get full benefits from DP and reduce risk)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants