I agree with Kevin, having to endpoints would be a bit confusing for the users (HTTP for this and HTTPS for others) as well as from the code perspective, also I am not sure how resource intensive two jetty servers would be, I hear that it is not that bad.
On Mon, Feb 25, 2019 at 9:54 AM Kevin Risden <kris...@apache.org> wrote: > I'm not a fan of adding a new endpoint. This port would need to be > configurable. We would need to ensure that it always points to the correct > location. > > Instead, can we download the cert from the existing HTTPS endpoint? We > would have to not trust the TLS connection to pull the public cert, but > this is the same as pulling the truststore over the HTTP endpoint you > proposed. This will guarantee we don't have to do anything special on > startup and will work with any configured TLS certificate. > > Kevin Risden > > > On Mon, Feb 25, 2019 at 9:44 AM Sandor Molnar <smol...@cloudera.com.invalid > > > wrote: > > > Hi folks, > > > > I've just started to think about how to resolve > > https://issues.apache.org/jira/browse/KNOX-1418 and an approach could > be: > > > > 1.) Server-side changes > > I'm thinking of starting a new embedded Jetty instance when the gateway > > server starts on a pre-configured port (e.g. 8100) with a simple HTTP > > connector. This connector would have only one handler: Jetty's > > ResourceHandler ( > > > > > https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/index.html?org/eclipse/jetty/server/handler/ResourceHandler.html > > ). > > Whenever the gateway is started we would export the public cert of the > > gateway into a dedicated folder (e.g. > > $GATEWAY_HOME/data/security/clientCert/gateway-client-trust.jks). We have > > to configure the ResourceHandler to allow access to this folder only > (thus > > nothing else will be exposed through this new endpoint). > > > > 2.) KnoxShell-side changes > > Within KnoxShell we should add a new command that simply hits the new > > endpoint and save the output in the root of the current user (for > instance > > curl http://c7401.ambari.apache.org:8100/gateway-client-trust.jks > > > ~/gateway-client-trust.jks) > > > > 3.) Optionally, we may change KnoxCLI to inform the end-user about the > new > > location of the JKS certificate in case the user executes `knoxcli.sh > > export-cert --type JKS` (it does not make sense to do the same what we > > already have) > > > > Any comments are highly appreciated! > > > > I've already coded a POC and it works as expected: > > > > $ rm -f ~/gateway-client-trust.jks > > > > $ curl http://c7401.ambari.apache.org:8100/gateway-client-trust.jks > > > ~/gateway-client-trust.jks > > % Total % Received % Xferd Average Speed Time Time Time > > Current > > Dload Upload Total Spent Left > > Speed > > 100 674 100 674 0 0 43602 0 --:--:-- --:--:-- --:--:-- > > 44933 > > > > $ ./bin/knoxshell.sh samples/ExampleWebHdfsLs.groovy > > Enter username: guest > > Enter password: > > [app-logs, ats, atsv2, hdp, mapred, mr-history, tmp, user] > > > > > > Thanks, > > Sandor > > >
