Allow getting AltsContext from transport attributes on client-side

[surbhigarg92]

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]

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.

[temawi]

@surbhigarg92 Do the ideas Eric provided work for you?

[surbhigarg92]

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]

Discussion from Friday:

• Using IP subnet is stable, as the IPv6 subnet is configured in firewall rules
• Seems AltsContextUtil should be made 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)

[surbhigarg92]

@ejona86 I was trying to use AUTH_CONTEXT_KEY to get AltsContext. But looks like this class in internal.

Also the method here takes the ServerCall , we are looking to get this info from Client.

Object authContext = call.getAttributes().get(AltsProtocolNegotiator.AUTH_CONTEXT_KEY);
   if (!(authContext instanceof AltsInternalContext)) {
     throw new IllegalArgumentException("No ALTS context information found");
   }

[ejona86]

When I said:

Seems AltsContextUtil should be available on client-side

That was meaning, "we should change things to make it available." I've changed the language in the comment to "Seems AltsContextUtil should be made available on client-side"

[surbhigarg92]

Is there an ETA for this ?

[ejona86]

#11634 added an AltsContextUtil.check(Attributes) method which can be passed clientCall.getAttributes() to learn if ALTS was used. I'll leave this open to still provide the context details, like is available on server-side, and to provide a check(ClientCall) convenience to mirror the server-side API.