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 < > [email protected] <javascript:>> 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/oauth/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 < >>> [email protected]> 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, [email protected] 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/topic/grpc-io/ifL63H0kN48/unsubscribe. >>>> To unsubscribe from this group and all its topics, 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/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/topic/grpc-io/ifL63H0kN48/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/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 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/5e90ddba-490d-432f-8418-c74572ab84ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
