How to Secure Apache Zeppelin with HTTPS and Command Restrictions in 4 Hours

This article documents the process of enabling HTTPS for Apache Zeppelin and hacking its source code to meet a client’s security requirements.

Background

The client’s Chinese branch commissioned a penetration test to verify internal network security. The test revealed two issues: Zeppelin was accessed over HTTP inside the intranet, and it allowed execution of shell commands and Python code. Although Zeppelin is designed for such tasks, the client considered these risks unacceptable.

HTTPS Configuration – Part 1 (Domain Certificate)

We used an existing domain certificate to create a Java Keystore (JKS) for Zeppelin. The steps involved importing the certificate and configuring Zeppelin to use it for HTTPS.

HTTPS Configuration – Part 2 (Self‑Signed Certificate for Mutual TLS)

If mutual authentication is required, we generated a self‑signed certificate, created a JKS, and configured both server and client truststores. For single‑direction authentication, only the server keystore is needed.

Deploying the Certificates

After generating the keystore files, we placed them on the server, updated Zeppelin’s configuration to point to the keystore, and restarted the service. The reverse proxy (nginx) was also configured with an SSL certificate on port 443 and an upstream to Zeppelin’s internal port 8443.

Source Code Hardening

To satisfy the client’s request for command restrictions, we examined Zeppelin’s source code to locate the Java class that forwards user input to the interpreter. Zeppelin’s architecture includes a Jetty backend, Angular frontend, Shiro for authentication, and interpreter plugins communicating via sockets.

We identified the relevant .java file (name omitted for suspense) and inserted a simple validation check that blocks execution of shell commands and arbitrary Python code. The modified code was compiled, the resulting JAR replaced the original, and configuration files were updated accordingly.

Result

After redeploying Zeppelin with the new HTTPS settings and hardened source code, the follow‑up penetration test passed without issues. The entire process, from certificate setup to source modification, was completed in about four hours, well ahead of the client’s deadline.