{% include JB/setup %}

This page explains what security characteristics can be expected from Apache Zeppelin, what measures operators of a Zeppelin instance will have to take, and how to report any security issues found in the Zeppelin software.

It is the nature of the Zeppelin software that it allows uploading code from the browser and executing it on the server.

Because of this, you should make sure your Zeppelin instance is only available to trusted users, and the server on which Zeppelin is installed does not contain any secrets or have privileges beyond those the users are trusted with.

All interpreters should be assumed to be able to access the local shell and execute arbitrary commands with the privileges of the user running the Zeppelin server. As generic interpreters such as sh, Groovy, Java and Python make this especially trivial, we plan to disable the sh interpreter by default from version 0.11.1 onward.

This is the component that we get the most Security reports about. Many JDBC drivers have support for specifying powerful query parameters in the JDBC URLs. Many of the driver jars have security issues that are fixed in newer versions. Zeppelin users should be very careful about which jars they add to their Zeppelin deployments. Always use the latest available jars and ensure that you set up Zeppelin on a secure network to stop malicious users gaining access to your deployment (see below).

Note: The JDBC connection string (URL) can accept a variety of parameters, some of which may have significant security implications. In untrusted or shared environments, you must carefully review and monitor all parameters included in the JDBC URL. Certain parameters can enable features such as external network access, file access, or privilege escalation, which may introduce security risks. Always ensure that only safe and intended parameters are used, and regularly audit connection strings for suspicious or unnecessary options.

When the Zeppelin interpreter is run in a Docker container, this isolates the operating environment of the interpreter through the Docker container. This isolation can provide an operational benefit on large deployments, but is not intended as a security boundary: access to your Zeppelin instances should be restricted regardless of how they are deployed.

When Zeppelin is deployed on Kubernetes, Zeppelin creates pods for individual interpreters. Also, the Spark interpreter is auto configured to use Spark on Kubernetes in client mode. This isolation can provide an operational benefit on large deployments, but is not intended as a security boundary: access to your Zeppelin instances should be restricted regardless of how they are deployed.

If you want to allow access to a Zeppelin server across a network, you should consider what files and other OS and network resources that the OS user used to run the server has access to. Zeppelin users will be able to access these. Using a Docker container or equivalent might be one way to limit what is accessible. Alternatively, you could look at setting the permissions for the OS user used for running the Zeppelin server process.

Zeppelin allows notes to produce rich output, including HTML and even executing JavaScript code. This means that when users view each others' notes, HTML and JavaScript controlled by the creator of the note will be executed in the browser that views it.

Because of this, you should make sure your Zeppelin instance is only available to trusted users. When deploying Zeppelin on a domain that is shared with other applications, appropriate measures may have to be taken to avoid a compromised Zeppelin notebook to also grant access to other services on the same domain.

If you expose your Zeppelin instance on a network you don't fully trust, you should configure Apache Shiro authentication.

Non-authenticated users cannot view, store or execute notes, so they cannot execute code on the server or on other users' browsers. Authenticated users, however, have the same access as described above, so even when using authentication it is still important to only give trusted users access to Zeppelin. Specifically, users technically have access to all notes by other users.

When running Zeppelin service, be mindful that it utilizes executables which might be pre-installed on your server or container. These executables could potentially be altered for malicious purposes. To mitigate this risk, it's recommended to set the paths to trusted locations for these executables, such as PYTHON and SPARK_HOME.

It is always best to use the latest Apache Zeppelin release. A good place to check for CVE announcements is the Zeppelin users mailing list. Many third party sites maintain lists of CVEs by product. One example is OpenCVE.

If you have found a potential security issue in Apache Zeppelin, such as a way to bypass the Shiro authentication, we encourage you to report this problem at security@zeppelin.apache.org. This is a private mailing list. Please send one plain-text email for each vulnerability you are reporting.

An overview of the vulnerability handling process is:

• The reporter reports the vulnerability privately to security@zeppelin.apache.org.
• The Zeppelin project security team works privately with the reporter to resolve the vulnerability.
• The Zeppelin project creates a new release of the package the vulnerability affects to deliver its fix.
• The Zeppelin project publicly announces the vulnerability and describes how to apply the fix.

Committers should read a more detailed description of the process. Reporters of security vulnerabilities may also find it useful.