In order to secure access to the Zeppelin UI, we will want to enable TLS (as well as authentication) to ensure confidentiality of communication and to assure the identity of the Zeppelin server. Zeppelin uses Jetty as the underlying HTTP server, so we'll refer to Jetty documentation.
In this how-to we'll use a self-signed certificate. In Production environments, you will likely obtain a CA-issued certificate or a trusted root certificate from your PKI team specific to your environment.
Since self-signed certificates won't be trusted by your browser by default, we'll show how to trust this certificate on OS X 10.11.6 with Chrome version 55.0.2883.95 (other OS/browser combinations are out of the scope of this article).
To generate the self-signed certificate, we'll use the openssl and keytool utilities as follows (see this Jetty doc for reference):
openssl genrsa -des3 -out zeppelin.key openssl req -new -x509 -key zeppelin.key -out zeppelin.crt keytool -keystore keystore -import -alias zeppelin -file zeppelin.crt -trustcacerts openssl pkcs12 -inkey zeppelin.key -in zeppelin.crt -export -out zeppelin.pkcs12 keytool -importkeystore -srckeystore zeppelin.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
These steps, respectively:
1) create a new private key
2) create a new self-signed certificate using this key
3) imports this self-signed certificate into a new keystore (called "keystore")
4) creates a PCKS12 file that combines the private key and certificate chain
5) converts this PCKS12 file to JKS format and imports it into the keystore
We'll then need to move this keystore to the appropriate location with the appropriate ownership and permissions:
mv keystore /usr/hdp/zeppelin-server/conf chown zeppelin:zeppelin /usr/hdp/zeppelin-server/conf
Finally, we'll configure Zeppelin to use TLS in Ambari.
There is currently a bug affecting HDP 2.5.0 and 2.5.3 regarding using relative paths for the keystore and truststore.
This bug was introduced by ZEPPELIN-1319, namely, when using a relative path like conf/keystore, Zeppelin server is unreachable and the error in the logs is as below. ZEPPELIN-1810 fixes the bug introduced by ZEPPELIN-1319. The error looks like:
FAILED SslContextFactory@6cd166b8(/usr/hdp/current/zeppelin-server/conf/null,/usr/hdp/current/zeppelin-server/conf/null): java.io.FileNotFoundException: /etc/zeppelin/2.5.0.0-1245/0/null (No such file or directory)
However, with absolute paths for the keystore and truststore paths, such as /usr/hdp/current/zeppelin-server/conf/keystore, Zeppelin server starts normally and is reachable over HTTPS.
Now we need to ensure that our Chrome browser trusts this self-signed certificate. We need to copy the certificate to our Desktop (click the broken HTTPS link > Details > View Certificate and drag and drop to the desktop).
We can then import the certificate into our OS X keychain and set it as trusted:
Make sure you restart Chrome. After doing so, you should see the green lock icon next to the HTTPS URL and should no longer see a browser warning,
