Is there an update on this topic? This feature would also be useful for my application utilizing gRPC to communication local host between services
On Wednesday, April 18, 2018 at 5:12:40 PM UTC-4 Colin Morelli wrote: > 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 < > [email protected]> 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 < >>> [email protected]> 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]. >>>> 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/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 >> [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 >> >> <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/88f6616a-d64a-4fba-8a29-2f8f929b242en%40googlegroups.com.
