Hi Nathaniel, Wondering if you have a bit of time to think about this. This is an outgoing issue for a feature we are working on vitess <http://www.vitess.io>. To give you more context, I'm adding a link to the Vitess github issue to this thread.
https://github.com/youtube/vitess/pull/3418 Best, On Fri, Nov 10, 2017 at 3:55 PM, Rafael Chacon <[email protected]> wrote: > Hi Nathaniel, > > Thank you for your reply. > > In our deployment we use GRPC only between components that are part of our > network, which is secured at a lower layer of the stack. Our general > approach is _not_ to require all of our applications to implement transport > level security or encryption, as that service is supplied by the network > level. > > However, we would like to extend the GRPC communication to support > user-based authentication / authorization which by definition is an > application-specific construct. > > Although I understand that it would be possible for a naive user to leak > credentials if they used an insecure channel but used credentials on it, > the current implementation stance of python GRPC prevents us from using > authorization without an unnecessary (and undesired) level of transport > encryption. > > One proposal we considered to handle this would be to have a "null" > channel credentials object -- i.e. make it an obvious decision by the > application programmer to use call credentials _without_ channel security. > > Specifically, the call site would be something like: > > grpc.composite_channel_credentials( > grpc_insecure_channel_credentials(), > my_custom_call_credentials() > ) > > On Fri, Nov 10, 2017 at 3:00 PM, Nathaniel Manista <[email protected]> > wrote: > >> On Thu, Nov 9, 2017 at 6:13 PM, <[email protected]> wrote: >> >>> By looking at this thread >>> <https://www.mail-archive.com/[email protected]/msg01161.html>, >>> it seems that the python client requires a secure channel to send >>> credentials. >>> >> >> Yes, this was a deliberate decision and I think there's even logic in >> gRPC Core to prevent the accidental transmission of clients over unsecured >> channels. >> >> This is not the case in golang (it is an option >>> <https://github.com/grpc/grpc-go/blob/master/credentials/credentials.go#L42> >>> ). >>> >>> Is there any workaround in python for this? >>> >> >> There is no currently-supported workaround and... I'm not even sure I >> could come up with an unsupported workaround. >> >> Are there any plans to support it with an interface like the one defined >>> in go? >>> >> >> There are no such plans at this time. >> >> Can you tell us more about your use case? >> -Nathaniel >> > > -- 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/CAB_5eU6EW4duBfYiKs4Y3G6HK8zvkDQVbi%2BtHO%2BYVdQQ%3D7RUTA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
