Python grpc.metadata_call_credentials over insecure channel

[rch...@slack-corp.com]

Hi all -

 

By looking at this thread, it seems that the python client requires a secure channel to send credentials. This is not the case in golang (it is an option). 

Is there any workaround in python for this? Are there any plans to support it with an interface like the one defined in go? 

Best, 

Rafael. 

[Nathaniel Manista]

On Thu, Nov 9, 2017 at 6:13 PM, <rch...@slack-corp.com> wrote:

By looking at this thread, 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).

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

[Rafael Chacon]

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()

)

[Rafael Chacon]

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. 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,

[Ken Payson]

I think there are other ways to accomplish what you are describing.

Insecure channels still support custom metadata, which can be passed to stubs using the optional "metadata" field.

Here is an example.

As Nathaniel mentioned, it is unlikely that credentials will be allowed on insecure channels given that it was a deliberate restriction.

[rch...@slack-corp.com]

Thank you Ken,

That was exactly what I was looking for!