I'll echo the reservations around the overhead (config, performance, etc...) associated with an additional endpoint.
I like the idea of leveraging the browser (cited by Larry), which already has a built-in mechanism for allowing the user to explicitly allow the interaction with the potentially untrusted Knox endpoint (e.g., self-signed cert deployment). The solution might be as simple as a download link on the Admin UI. The KnoxShell command could use loginInsecure() to access that link location, presuming it will be a well-known resource path. Thanks, Phil On Mon, Feb 25, 2019 at 10:06 AM larry mccay <[email protected]> wrote: > 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 <[email protected]> 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 > <[email protected] > > > > > 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 > > > > > >
