Hello devs and users, I would like to follow up on the recent, valuable discussion regarding the Apache Zeppelin security model, initiated by the ASF Security Team.
We believe the most practical path forward is to proceed with the proposal to simplify and clarify our security model. This means that for all deployment types, including Docker and Kubernetes, we will operate under the assumption that all users with access to a Zeppelin instance are trusted. It is important to clarify that this change in the security model does not diminish our commitment to security hardening. While the model helps define what constitutes a formal vulnerability, we will continue to proactively enhance security to protect our users and reduce potential risks. To that end, we have already taken the first steps: 1. *Updated Documentation:* We have updated the official security documentation to clearly reflect this unified security stance. The changes can be reviewed in this commit: https://github.com/apache/zeppelin-site/commit/49e74fafa164ffb0199e965328ae41dd036e8088 2. *Ongoing Code Hardening:* We are simultaneously continuing our efforts to harden the codebase. An example of this is the ongoing work to implement stricter controls on JDBC connection parameters: https://github.com/apache/zeppelin/pull/4949 We will continue to update our security model and documentation as the project evolves, and efforts like the one above will remain a priority. We consider this the best course of action for now, but we always welcome community feedback. If you have further thoughts, concerns, or proposals, please feel free to restart the discussion by replying to this email thread at any time. Thank you again for your engagement in making Zeppelin better and more secure. Best regards, Jongyoul Lee 2025년 7월 4일 (금) 오전 7:24, Jongyoul Lee <jongy...@gmail.com>님이 작성: > Hello ASF Security Team, > > Thank you for initiating this discussion and for your proposals regarding > Apache Zeppelin's security posture. > > Based on my experience operating Zeppelin in production environments, I > agree with the premise that users accessing the same instance must be > trusted. Given the direct execution of user code, my teams have > consistently utilized instances with trusted users. We often deployed > smaller, team- or individual-specific Zeppelin servers, and used separate > instances for sharing to maintain clear operational boundaries. > > Therefore, I believe trusting users within the same instance is a valid > and practical approach for Zeppelin deployments. > > I hope this discussion's outcome alleviates security burdens for user-code > execution projects like Zeppelin, allowing them to focus on core > development. This clarity should significantly contribute to the project's > evolution, enabling the community to prioritize feature enhancement and > innovation. > > Please reach out with any questions or feedback. > > Best regards, > Jongyoul Lee > > > 2025년 7월 3일 (목) 19:29, Arnout Engelen <enge...@apache.org>님이 작성: > >> Hello, >> >> As shared before[0], the ASF security team is concerned about the ability >> of the Zeppelin project to respond to security issues. >> >> In the vast majority of Zeppelin deployments, either the network or Shiro >> needs to be configured to make sure only trusted users have access. Those >> users must be assumed/trusted to be able to view and manipulate each >> other's resources, as per the security model[1]. >> >> Zeppelin also supports Docker/K8s deployments where the running user code >> is isolated from the Zeppelin infrastructure. It seems the bottleneck in >> making security decisions is that it can be difficult to assess whether a >> potential issue in Zeppelin code could be used to bypass that isolation. >> For that reason, we propose to stop advertising this isolation as a >> security boundary. This means even in Docker/K8s deployments users are >> trusted, and can in theory view and manipulate each other's resources. The >> isolation can still be useful from an operational perspective, for example >> when you have one Zeppelin instance that is shared across multiple >> (trusted) teams. >> >> We'd like to gather feedback on whether this would be problematic for any >> significant Zeppelin deployments. If so, please reach out ASAP - but note >> we will ask you to play an active role in making security assessments for >> this use case. >> >> >> [0]: https://lists.apache.org/thread/c6zygxpg6woxttsxwojkt60vvs1f2njx >> [1]: https://zeppelin.apache.org/security.html >> >> -- >> Arnout Engelen >> ASF Security Response >> Apache Pekko PMC member, ASF Member >> NixOS Committer >> Independent Open Source consultant >> > -- Best regards, Jongyoul Lee
