Hi T Wang, The kernel gateway is based on the same code as the notebook server which means its fundamentally a single-user service. Multitenancy is gained by running multiple gateways, authenticating users with an external service, routing all user traffic to the correct gateway instance and the kernels it spawns, and isolating users kernels from one another (lest one user execute code to discover how to talk to other user kernels).
Cheers, Pete On Tuesday, October 11, 2016 at 6:17:36 PM UTC-4, T Wang wrote: > > Hi, > I would like to have the Jupyter Kernel Gateway sits on my Spark cluster's > master / edge node. It takes the client requests in HTTP or web-socket to > create different Jupyter Kernels for clients. I have a question regarding > to how Jupyter Kernel Gateway handles multi-tendency. For example, I have > multiple users who speak Jupyter protocol to access the Jupyter Kernel > Gateway remotely in order to launch Spark jobs on the cluster. The Jupyter > Kernel Gateway sites on my cluster's master / edge node. It takes the > requests and creates multiple Kernels, say Kernel A and Kernel B inside of > the Spark cluster. > > now I have user 1 and user 2 interactively accessing the same Kernel A and > user 3 and 4 accessing the kernel B. How does Jupyter Kernel Gateway makes > sure that the correct users are mapped to their own kernels and isolate the > wrong users to access others' kernels. Does Jupyter Kernel Gateway > implement impersonation? > > Regards, > Tanping > > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/d3fc08cc-c46c-48f0-89b3-077693e81210%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
