What is the use case for this? If a user just wants to download the TLS certificate, couldn't they execute the following on the command line?
openssl s_client -connect *knoxhost*:*knoxport* -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > knox_gateway.pem Then the user can import the PEM file into their truststore. Or maybe the KnoxCLI can do this for the user. On Mon, Feb 25, 2019 at 10:48 AM Phil Zampino <[email protected]> wrote: > 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 > > > > > > > > > >
