[Java] Override authority

625 views
Skip to first unread message

vadim....@gmail.com

unread,
Aug 9, 2017, 4:56:05 PM8/9/17
to grpc.io
Hello,

What's the right way to override authority for a channel or stub?

I see there is withAuthority method in CallOptions, but there is no withAuthority method in AbstractStub and I cannot pass CallOptions to generated stubs.

There is overrideAuthority method in ManagedChannelBuilder class, but the comment says "Should only used by tests".

In gRPC C# I can do something like that:

var channel = new Channel(
    "myproxy:4140",
    ChannelCredentials.Insecure,
    new []{new ChannelOption(ChannelOptions.DefaultAuthority, "original-authority")});

Thanks.

Ryan Michela

unread,
Aug 9, 2017, 5:12:28 PM8/9/17
to grpc.io, vadim....@gmail.com
I've used ManagedChannelBuilder.overrideAuthority() to point to a proxy without issue. I don't know if that's "supported", but it works.

Eric Anderson

unread,
Aug 10, 2017, 3:31:29 PM8/10/17
to vadim....@gmail.com, grpc.io
On Wed, Aug 9, 2017 at 1:56 PM, <vadim....@gmail.com> wrote:
What's the right way to override authority for a channel or stub?

I see there is withAuthority method in CallOptions, but there is no withAuthority method in AbstractStub and I cannot pass CallOptions to generated stubs.

The withAuthority in CallOptions is a bit dangerous because it doesn't currently verify the TLS certificate when being used.

There is overrideAuthority method in ManagedChannelBuilder class, but the comment says "Should only used by tests".

In gRPC C# I can do something like that:

var channel = new Channel(
    "myproxy:4140",
    ChannelCredentials.Insecure,
    new []{new ChannelOption(ChannelOptions.DefaultAuthority, "original-authority")});

The equivalent of that in Java is ManagedChannelBuilder.overrideAuthority(). The only reason that works though is because you are using insecure. I'm assuming that the proxy is a TCP-level proxy that knows nothing of HTTP/2.

How does the proxy know where to proxy to? Normally we'd expect to see an HTTPS proxy and we'd use HTTP's CONNECT to form a connection.

vadim....@gmail.com

unread,
Aug 10, 2017, 4:37:53 PM8/10/17
to grpc.io, vadim....@gmail.com
I use https://linkerd.io/ for the proxy - it performs load balancing and name resolution. It is HTTP/2 aware and uses authority header by default to resolve names.

Yes, I use insecure channels and need to route certain connections only through the proxy, so setting global http proxy will not work.

Ryan Michela

unread,
Aug 10, 2017, 5:20:45 PM8/10/17
to vadim....@gmail.com, grpc.io
We use linkerd as well and found a neat trick for routing grpc requests to the proxy without having to muck with the Authority header. We added a magic "localhost" domain name to our dns where all subdomains point to 127.0.0.1. In the client builder, we set the destination to servicename.mesh.company.com:4140, which resolves to 127.0.0.1:4140. Linkerd is listening on port 4140.

In our linkerd and dtab configuration, we use the http-2-header-token-identifier to extract the :authority header from the grpc request. We run the result through the subdomainofpfx namer to extract just the leftmost part of the authority header ("servicename" in the above example). Finally, pass the service name to the Zookeeper serversets announcer to resolve the service name into a set of hosts and ports from our discovery system. 

The dtab looks something like
/authority => /svc ;
/svc       => /#/io.bouyant.http.subdomainOfPfx/mesh.company.com/s ;
/s         => /#/io.l5d/serversets/services ;



--
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/RK8fsCIOHDk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/446c1de1-11c6-4fef-9480-fbaec7d6fcb5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

vadim....@gmail.com

unread,
Aug 10, 2017, 5:37:39 PM8/10/17
to grpc.io, vadim....@gmail.com
That's pretty cool. We use linkerd inside of DC/OS and configured marathon namer to resolve ip addresses from :authority header. Since we have to use Mesos DNS (part of Marathon) there is not much we can do except overriding :authority.

Thanks.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

Ryan Michela

unread,
Aug 10, 2017, 5:46:29 PM8/10/17
to vadim....@gmail.com, grpc.io
If you are willing to trust someone else to resolve "localhost" for you, you can leave your internal DNS untouched.


To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

vadim....@gmail.com

unread,
Aug 10, 2017, 6:07:39 PM8/10/17
to grpc.io, vadim....@gmail.com
Thanks for the idea. It's a bit more complicated as we run apps in containers in overlay network, which means each container has its own localhost. But adding some custom dns config might be an option. Thanks.

Eric Anderson

unread,
Aug 15, 2017, 4:32:37 PM8/15/17
to Vadim Ivanou, grpc.io
Ah, then ManagedChannelBuilder.overrideAuthority() seems to be what you want. Linkerd is acting as a reverse proxy, so it "is" the server as far as gRPC is concerned. Your environment could have been configured by overriding DNS to point to linkerd; that's functionally similar to using overrideAuthority.

On Thu, Aug 10, 2017 at 1:37 PM, <vadim....@gmail.com> wrote:
--
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 grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

vadim....@gmail.com

unread,
Aug 16, 2017, 11:33:26 AM8/16/17
to grpc.io, vadim....@gmail.com
Thank you, we'll be definitely looking at DNS config changes too.


On Tuesday, August 15, 2017 at 4:32:37 PM UTC-4, Eric Anderson wrote:
Ah, then ManagedChannelBuilder.overrideAuthority() seems to be what you want. Linkerd is acting as a reverse proxy, so it "is" the server as far as gRPC is concerned. Your environment could have been configured by overriding DNS to point to linkerd; that's functionally similar to using overrideAuthority.
On Thu, Aug 10, 2017 at 1:37 PM, <vadim....@gmail.com> wrote:
I use https://linkerd.io/ for the proxy - it performs load balancing and name resolution. It is HTTP/2 aware and uses authority header by default to resolve names.

Yes, I use insecure channels and need to route certain connections only through the proxy, so setting global http proxy will not work.

On Thursday, August 10, 2017 at 3:31:29 PM UTC-4, Eric Anderson wrote:
On Wed, Aug 9, 2017 at 1:56 PM, <vadim....@gmail.com> wrote:
What's the right way to override authority for a channel or stub?

I see there is withAuthority method in CallOptions, but there is no withAuthority method in AbstractStub and I cannot pass CallOptions to generated stubs.

The withAuthority in CallOptions is a bit dangerous because it doesn't currently verify the TLS certificate when being used.

There is overrideAuthority method in ManagedChannelBuilder class, but the comment says "Should only used by tests".

In gRPC C# I can do something like that:

var channel = new Channel(
    "myproxy:4140",
    ChannelCredentials.Insecure,
    new []{new ChannelOption(ChannelOptions.DefaultAuthority, "original-authority")});

The equivalent of that in Java is ManagedChannelBuilder.overrideAuthority(). The only reason that works though is because you are using insecure. I'm assuming that the proxy is a TCP-level proxy that knows nothing of HTTP/2.

How does the proxy know where to proxy to? Normally we'd expect to see an HTTPS proxy and we'd use HTTP's CONNECT to form a connection.

--
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 grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
Reply all
Reply to author
Forward
0 new messages