jupyterhub / zero-to-jupyterhub-k8s

Helm Chart & Documentation for deploying JupyterHub on Kubernetes
https://zero-to-jupyterhub.readthedocs.io
Other
1.56k stars 798 forks source link

Document how to enable FUSE safely #3300

Open jhamman opened 11 months ago

jhamman commented 11 months ago

In https://github.com/pangeo-data/pangeo/issues/190, @yuvipanda has documented how to enable FUSE safely in the z2jh context. That issue has served as a reference for the Pangeo project and @yuvipanda suggested I transfer it here for greater visibility.

The first part of the issue from @yuvipanda is below👇

Use a daemonset with rshared mounts to mount FUSE

Currently, each user mounts fuse themselves. This has negative security consequences, since they require privileged containers to do this.

Long term, the solution is to implement a Container Storage Interface driver for GCS FUSE. The CSI standard has wide adoption across multiple projects (mesos can also use it, for example), while FlexVolumes are kubernetes specific. FlexVolumes are also deprecated in Kubernetes now, and will be removed in a (far future) release. CSI is more flexible.

For the near term, it would be great to do something that lets us let go of GCS Fuse.

I'm assuming the following conditions are true for the FUSE usage:

  1. Everyone has same access to the entire FUSE space (read/write)
  2. We can upgrade to Kubernetes 1.10 (which should be on GKE in a few weeks)

We can use the new support for rshared mounts in kubernetes 1.10 to do the following:

  1. Make a container that has all the software for doing the GCS Mount.
  2. Run this container as a privileged daemonset - this makes it run on all nodes.
  3. Mount GCSFuse as /data/gcsfuse on the host machine, via rshared mounts.
  4. For each user node, mount /data/gcsfuse with hostPath into their user pod. They can use this for accessing GCSFuse without needing privileged access.

How does this sound?


An alternative if we want to do this earlier is:

  1. Switch node type to Ubuntu in GKE
  2. Run something like https://github.com/berkeley-dsep-infra/data8xhub/tree/master/images/mounter in a daemonset. In that example, we run this script: https://github.com/berkeley-dsep-infra/data8xhub/blob/master/images/mounter/mounter.py on the host. We can instead run something that mounts GCS FUSE instead.

This can happen today if needed.

welcome[bot] commented 11 months ago

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. welcome You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

yuvipanda commented 11 months ago

This is a common enough thing that folks ask for, and very easy to footgun by just giving users full root with privileged, we should document how to do this properly somewhere.