This is an automated email from the ASF dual-hosted git repository.
jongyoul pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/zeppelin-site.git
The following commit(s) were added to refs/heads/master by this push:
new d32cf1363 Add deployment considerations for Zeppelin security (#34)
d32cf1363 is described below
commit d32cf13634d63fddd4def75b6d74756281a622cf
Author: PJ Fanning <[email protected]>
AuthorDate: Tue Nov 11 17:23:46 2025 +0100
Add deployment considerations for Zeppelin security (#34)
* Add deployment considerations for Zeppelin security
Added a section on deployment considerations for Zeppelin servers,
including access control and resource limitations.
* Update security.md
Co-authored-by: Arnout Engelen <[email protected]>
---------
Co-authored-by: Jongyoul Lee <[email protected]>
Co-authored-by: Arnout Engelen <[email protected]>
---
security.md | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/security.md b/security.md
index a486043b2..0b1e92201 100644
--- a/security.md
+++ b/security.md
@@ -69,6 +69,15 @@ Also, the Spark interpreter is auto configured to use Spark
on Kubernetes in cli
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.
+### Deployment
+
+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.
+
## JavaScript code execution in the browser
Zeppelin allows notes to produce rich output, including HTML and even
