On 2025/07/12 04:58:15 Jongyoul Lee wrote: > 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.
I think this is a great move and fits the project much better. > *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 Since there seems to be consensus on the approach, I think we can make some more simplifications: * remove the "Zeppelin on Docker" section * remove the "Zeppelin on Kubernetes" section * remove the segment "unless Docker or K8s isolation has been configured as mentioned above, " in the "Authentication" section Would you like to PR those changes or would you like me to propose them to the repo? Kind regards, Arnout > 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 >
