Hi Sandor - Thanks for starting this discussion and taking up that task!
+1 to Kevin's points. KnoxSession already has a loginInsecure() method as well. I also think that it needs to be available from the Admin UI - in which case the SSL cert is already trusted by your browser or the exception already added. The API use from KnoxShell is a bit odd as there is no protection against a MITM returning a cert and intercepting all KnoxShell requests. I'd like the primary mechanism to be a download link. At least when the cert is CA signed, the browser will validate the hostname and that it is trusted as part of the download whereas the loginInsecure() will not. Perhaps, we should try login() first and when it fails hostname validation then we fallback to loginInsecure(). thanks, --larry 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 > > >
