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
>
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,
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
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
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
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
+ 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
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
Sorry for the quick double post here, but just wanted to clarify point #3
above. I understand JWTs are still private in the sense that you could beat
the caller to the server with the same credentials it is trying to use (or
rely on the fact that the service isn't using the JTI as a nonce). In
