Zeppelin Security
This page explains what security characteristics can be expected from Zeppelin, what measures operators of a Zeppelin instance will have to take, and how to report any security issues found in the Zeppelin software.
Code execution on the server
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.
Zeppelin on Docker
An exception to the above is when the Zeppelin interpreter is run in a Docker container. This isolates the operating environment of the interpreter through the docker container.
Zeppelin on Kubernetes
A similar exception exists when Zeppelin is deployed on Kubernetes. In this case Zeppelin creates pods for individual interpreters, and also the Spark interpreter is auto configured to use Spark on Kubernetes in client mode.
JavaScript code execution in the browser
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.
Authentication
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, unless Docker or K8s isolation has been configured as mentioned above, users technically have access to all notes by other users.
Executable verification
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.
Reporting security issues
If you have found a potential security issue in 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.
Vulnerability handling
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.