Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how to enable FUSE safely #3300

Open
jhamman opened this issue Dec 16, 2023 · 2 comments
Open

Document how to enable FUSE safely #3300

jhamman opened this issue Dec 16, 2023 · 2 comments

Comments

@jhamman
Copy link
Contributor

jhamman commented Dec 16, 2023

In pangeo-data/pangeo#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.

Copy link

welcome bot commented Dec 16, 2023

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

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! 👋

Welcome to the Jupyter community! 🎉

@yuvipanda
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants