Hey group,

I've seen discussions before about CallCredentials and their ability to be 
used on insecure channels. It seems that, at least today, they can't be 
used for any C-based implementations of gRPC. I wanted to propose a change 
to that, and suggest CallCredentials should be able to be used on insecure 
channels (even if an option is required to enable this behavior). There are 
a couple of reasons I think this should be changed:

1) At least gRPC-java does support this. At best, the inconsistency is 
strange, at worst it could learn to painful realizations down the road if 
starting on gRPC and assuming that similar patterns will "just work" on 
other languages. This is what happened in my case, where our gRPC-Java 
implementations worked fine, but attempting to do the same thing in Node 
did not work and took a while before I realized this was the reason.
2) While I understand gRPC's belief that it's insecure to exchange tokens 
over plaintext channels, the reality is that the application-level 
implementation really has no idea what channel the data will actually be 
exchanged over. For example, in Istio deployments, the application may 
think it's communicating insecurely (and thus not allow CallCredentials to 
be sent), when in fact the traffic is going to hit an external container 
that will perform mTLS auth with the destination service. From the client 
and server perspective, this is an insecure channel, but in reality - it's 
not (unless you're concerned about the ability to tcpdump the loopback 
interface - at which point you're probably screwed anyway).
3) There are plenty of cases where the CallCredentials themselves are not 
necessarily private, and thus may be fine to exchange over plaintext (think 
JWTs). This could be the case in scenarios where the services themselves 
are not dealing with private information, but perhaps they perform an 
action that should still be authenticated. Understandably, everything 
should be TLS anyway, but see point #2 for cases in which the service might 
be using TLS in ways that gRPC may not know about.
4) Finally, from a developer experience perspective, it's still possible to 
send this information anyway - but it results in more fragile 
implementations of gRPC clients. For example, in Node, I've worked around 
this limitation by simply pre-generating Metadata instances that can be 
passed to calls (instead of using CallCredentials), but this requires me to 
take care to ensure that, at all call-sites, I have valid metadata (i.e. it 
hasn't expired since it was generated). CallCredentials provide a single 
way for me to do this, but it's currently not possible because of the 
restriction to use secure channels.

Hopefully, these are some compelling reasons to consider it. But, if not, 
at least this should hopefully start a conversation about the topic.

Best,
Colin

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6647b6d4-77c5-41ed-aea8-8c1e7e60e2e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to