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.
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.
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, unless Docker or K8s isolation has been configured as mentioned above, users technically have access to all notes by other users.
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 email@example.com. 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 firstname.lastname@example.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 vulnerabilty 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.