Missing Custom JKS and InsecureTrustManagerFactory support for ProxyEndpoint

[shahpankil]

Greetings,

We are evaluating to use zuul2 as our API gateway. For one of our use-case we observed following and seems this is either a defect or pending implmentation.

Use-case:

We have two backend services. One runs on HTTP and the other on HTTPS(self-signed certificates).
We use consul for service discovery and health. We do not use Eureka.
When we have below configuration in our application.properties for zuul server.

#Instance env settings

environment=dev
eureka.registration.enabled=false

#Loading Filters
zuul.filters.root=src/main/groovy/gateway/filters
zuul.filters.locations=${zuul.filters.root}/endpoint,${zuul.filters.root}/inbound,${zuul.filters.root}outbound
#zuul.filters.packages=com.netflix.zuul.filters.common

eureka.validateInstanceId=false
eureka.shouldFetchRegistry=false

ribbon.NFLoadBalancerClassName=com.netflix.loadbalancer.DynamicServerListLoadBalancer
ribbon.NIWSServerListClassName=com.gateway.discovery.ServerList
ribbon.NFLoadBalancerPingInterval=60
#ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.WeightedResponseTimeRule

consul.root.path=/config/global
#Override below property to 10, if we want refresh to be quicker
consul.watch.seconds=60
webserver.ribbon.IsSecure=true
#webserver.ribbon.TrustStore=gateway.jks
#webserver.ribbon.TrustStorePassword=changeit
webserver.ribbon.IsHostnameValidationRequired=false
webserver.ribbon.IsClientAuthRequired=false

We observe that the the DefaultOriginChannelInitializer is used to make appropriate API call to the Origin service.
Here we also observe that 'webserver.ribbon.IsSecure=true' is appropriately getting used for adding the SSL handler[file:DefaultOriginChannelInitializer.initChannel()] , but the other properties to use our custom truststore 'webserver.ribbon.TrustStore=gateway.jks' and 'webserver.ribbon.IsHostnameValidationRequired=false' are not getting used to create appropriate SslContext[file:DefaultOriginChannelInitializer.getClientSslContext()]

Issues:

1. Allow users to specify truststore when using DefaultOriginChannelInitializer to connect to Origin.
2. If users are having self-signed certificate then using the config 'webserver.ribbon.IsHostnameValidationRequired=false' to let users not specify a truststore and instead hook-up 'InsecureTrustManagerFactory.INSTANCE' so that hostname validation passes.

So enhancement is required in method DefaultOriginChannelInitializer.initChannel(), and if 'webserver.ribbon.IsSecure=true' is set then we read other configs and create SslContext.
Other alternative is when creating 'DefaultOriginChannelInitializer' a third argument of type 'IClientConfig' is added so that the SslContext is created correctly when instantiating the object.

Questions:

1. Are our above observation valid ?
2. If not, is there an alternate way to resolve the issues which we mentioned? If yes, what are they ?
3. Is this due to partial implemenation done in ProxyEndpoint https #428 (as commented by JacobJohansen on 10 May 2018)?

Thanks.

[steffentemplin]

Hi @shahpankil,

in my opinion your observations are valid. For the same reason (among others) I have opened #642 today.

We are trying to realize better configurable origin HTTPS connections by extending some Zuul2 default implementations using inheritance:

• Extend com.netflix.zuul.netty.ssl.ClientSslContextFactory or com.netflix.zuul.netty.ssl.BaseSslContextFactory to provide a customized SslContext.
• The context is returned from an instance that extends com.netflix.zuul.netty.connectionpool.DefaultOriginChannelInitializer#getClientSslContext(), where it uses the custom factory.
• The ChannelInitializer is created and returned by overriding com.netflix.zuul.netty.connectionpool.DefaultClientChannelManager#createChannelInitializer()
• Create custom com.netflix.zuul.origins.NettyOrigin and com.netflix.zuul.origins.OriginManager implementations which use the customized ClientChannelManager.
• Register the custom OriginManager in the Guice module instead of BasicNettyOriginManager.

All in all this allows for a clean customization, but requires to copy most of BasicNettyOrigin. If our pull request is accepted it would make it more smooth.

Extending/customizing the code directly gives us a lot more control. Especially as Ribbon is not really used under the hood. Instead just parts of the IClientConfig instance are used to create a com.netflix.zuul.netty.connectionpool.ConnectionPoolConfig instance, which is then used by the classes that handle the outbound Netty channels.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.