Adding jiangtao@ for thoughts on this (providing an option to allow call credentials over an insecure channel)
On Monday, March 26, 2018 at 12:14:03 PM UTC-7, Colin Morelli wrote: > > 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 [email protected]. To post to this group, send email to [email protected]. 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/34834ca8-872d-40b7-9e97-91e835f35113%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
