Mounting EFS/NFS to home without root privileges

JupyterHub
1

I filed an issue in the docker-stacks repo, but I’m posting as here as well in case this belongs under support. It does seem to defy categorization to some extent.

Correct me if I’m wrong, but it looks like the start.sh script requires root privileges to mount NFS.

I understand that it subsequently deescalates, however, we’re using JupyterHub to provision notebooks on K8s and we want to provide a custom image field in the options form, but there’s no way for us to guarantee deescalation in that context, which is a show-stopper.

Is it possible to mount an EFS volume to the home directory without running the container as root? Has anyone successfully implemented a workaround for this configuration expectation?

2

Strictly speaking the mount is handled by the container platform (Docker, Kubernetes), not the container itself.

According to
https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html
the default EFS owner is root so either it needs to be chowned at run-time which obviously requires admin permissions inside the container, or you set the permissions before it’s mounted.

The above link suggests it might be possible to automate. If you manage to figure it out please share the solution!

3

Thanks, Manics! Maybe this can simply be handled at the PV / PVC level. I’ll do some experimentation and submit a PR if I find a solution.

4

It sounds like EFS now has support for dynamically provisioning Kubernetes volumes:

This may make things easier!

5

We messed around with that and found it cumbersome and high maintenance, then switched to GitHub - kubernetes-sigs/nfs-subdir-external-provisioner: Dynamic sub-dir volume provisioner on a remote NFS server.. Neither solution provides the ability to mount as non-root though. Both have open issues complaining about precisely this. Looking into an Access Point approach that I have high hopes for. If it works, I’ll submit a PR. Worst case scenario, there’s always an initContainer or the pre_spawn_hook, but both implementations seem kind of janky to me.

1 Like
6

Heads up @manics, I just submitted a PR to z2jh to include documentation that steps through how to use aws-efs-csi-driver along with an EFS Access Point to mount the EFS to the home directory as non-root.

Here’s the link: Add non-root EFS documentation by droctothorpe · Pull Request #2538 · jupyterhub/zero-to-jupyterhub-k8s · GitHub.

1 Like
7

We were able run non root pods running with NFS using the csi-driver-nfs and also nfs-subdir-external-provisioner by adding singleuser.extraPodConfig to the helm values. In both cases I think the default fsGid settings are ignored as a result of the extraPodConfig settings that we are using to enforce non-root pods so we need to add fsGroup manually to the securityContext.

  singleuser:
  ¦ extraPodConfig:       # Extra settings for spawed pods for Restricted
  ¦ ¦ securityContext:
  ¦ ¦ ¦ runAsUser: 1000
  ¦ ¦ ¦ runAsGroup: 100   # group 1000 not defined on quay.io images
  ¦ ¦ ¦ fsGroup: 100         # this is the fix for getting csi-driver-nfs to mount group=users
  ¦ ¦ ¦ seccompProfile:
  ¦ ¦ ¦ ¦ type: RuntimeDefault
  ¦ ¦ ¦ runAsNonRoot: true
  ¦ ¦ ¦ allowPrivilegeEscalation: false