Yeah - this would be using my own implementation of call credentials. I think it makes perfect sense for the credentials implementation itself to define if it's okay with an insecure channel or not. That option just doesn't seem to exist, today, for grpc-core.
On Wed, Apr 18, 2018 at 5:09 PM, jiangtao via grpc.io < grpc-io@googlegroups.com> wrote: > Thanks much for clarification! In your use case, you will define your own > call credentials, right? > > > On Wednesday, April 18, 2018 at 2:04:10 PM UTC-7, Colin Morelli wrote: >> >> There seems to be a misunderstanding here. I'm not sure how Istio is not >> a valid use case. You only brought up the case of talking to Google APIs - >> which is only one use for gRPC. I am referring to developers using Istio to >> call other services in their own service mesh. i.e. calls between two >> internal services on a local network which travel over an Istio service >> mesh. Is there a reason that's not a valid use case? In this case, the >> connection to the local Istio proxy is insecure on the loopback interface >> and can then be (optionally) upgraded to mTLS when leaving the host. >> >> Given the two options you mentioned, though, yes I am interested in 1. >> >> Best, >> Colin >> >> On Wed, Apr 18, 2018 at 4:52 PM, jiangtao via grpc.io < >> grp...@googlegroups.com> wrote: >> >>> Hi Colin, >>> >>> In the Istio scenario, if an application needs to call Google APIs, my >>> understanding is that it does not connect to local proxy, the app still >>> connects to Google API using SSL and use call credential on top of the >>> secure connection, envoy proxy will pass through the traffic. >>> >>> There are two cases here >>> 1. Developer of a call credential decides whether the call credential >>> can be sent through insecure channel. >>> 2. User/App decides whether call credential can be sent through insecure >>> channel. >>> I am assuming you are interested in case (1) >>> >>> In case (1). grpc core and wrapping languages only allow call >>> credentials on a secure channel. gRPC Go and Java allow developers to set >>> transport_security level on a call credential (e.g., in Golang, >>> https://github.com/grpc/grpc-go/blob/master/credentials/oaut >>> h/oauth.go#L107). If you develop your own call credential and you do >>> not require secure channel, you can set the RequireTransportSecurity >>> function to return false. >>> >>> We could update grpc core to potentially allow call credential to be >>> sent over insecure channel (based on developer's configuration). Google >>> call credentials such OAuth token will always require secure channel >>> through. Given Istio scenario you described is not a valid use case, we >>> will only implement when resource is available. >>> >>> >>> On Wednesday, April 4, 2018 at 4:23:20 PM UTC-7, Colin Morelli wrote: >>>> >>>> Which version of gRPC-Java was this removed from? I'd be curious to >>>> understand why it was removed. >>>> >>>> I totally understand that's the case for Google tokens, and that makes >>>> perfect sense to me for that particular use case, but many use cases for >>>> gRPC will take place on internal networks with their own concepts of >>>> authentication and security that may not rely on app-to-app TLS. I would >>>> say probably the strongest arguments in support of it (from my previous >>>> list) would be #2 and #4. >>>> >>>> Stated differently: Istio is likely to be the de-facto standard for >>>> building service meshes on Kubernetes. Istio also pushes for transparent >>>> mTLS authentication between containers. Currently, with this limitation, >>>> using Istio means that you cannot use CallCredentials, which is problematic >>>> because the type of team that would use Istio is likely doing so >>>> specifically because they have a service architecture. >>>> >>>> As for your other point: I get that placing credentials in Metadata is >>>> an option, but again, this requires me to ensure I've got valid metadata at >>>> every call site. In simple cases, this might be easy, but as the number of >>>> call sites for gRPC methods increases, the complexity of ensuring every one >>>> is properly generating metadata does as well. Centralizing that capability >>>> to CallCredentials means I can safely write it once and ensure it's >>>> enforced properly everywhere (i.e. as long as I'm passing around an >>>> instance of CallCredentials, I know it's going to be serialized properly on >>>> every request). Again, this isn't the end of the world, but it's certainly >>>> not going to help me build a better application. >>>> >>>> I'm definitely interested in staying updated on this discussion. >>>> >>>> Best, >>>> Coiln >>>> >>>> On Wed, Apr 4, 2018 at 7:10 PM, jiangtao via grpc.io < >>>> grp...@googlegroups.com> wrote: >>>> >>>>> + ejona@ >>>>> >>>>> gRPC-java does support CallCredentials over insecure channel >>>>> previously, but not any more. >>>>> >>>>> All the tokens for accessing Google cloud services require protection >>>>> of the tokens. Keep in mind that attacker can use the stolen token for >>>>> impersonation. For user defined tokens, you can always place the token in >>>>> the grpc metadata instead of using CallCredentials. >>>>> >>>>> Anyway, we may open up a way to pass CallCredentials on channels that >>>>> do not have channel credentials. The discussion has not been finalized. >>>>> Stay tuned. >>>>> >>>>> On Monday, April 2, 2018 at 11:57:02 AM UTC-7, apo...@google.com >>>>> wrote: >>>>>> >>>>>> 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 a topic in the >>>>> Google Groups "grpc.io" group. >>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>>> pic/grpc-io/ifL63H0kN48/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> grpc-io+u...@googlegroups.com. >>>>> To post to this group, send email to grp...@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/fde4dc38-45a5-42c7 >>>>> -a637-09163f679ab6%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/grpc-io/fde4dc38-45a5-42c7-a637-09163f679ab6%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "grpc.io" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>> pic/grpc-io/ifL63H0kN48/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> grpc-io+u...@googlegroups.com. >>> To post to this group, send email to grp...@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/ms >>> gid/grpc-io/dbb08d3d-1c69-4ef9-9c11-9c982b2b3553%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/dbb08d3d-1c69-4ef9-9c11-9c982b2b3553%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/grpc-io/ifL63H0kN48/unsubscribe. > To unsubscribe from this group and all its topics, 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/5e90ddba-490d-432f-8418-c74572ab84ca%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/5e90ddba-490d-432f-8418-c74572ab84ca%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAPtU-Up%2BTsGAc1%3D6oP9WmDbUyzSjwmqpCf%3DO9vVX6oNaSQd8mA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
