search

jupyterhub / kubespawner

Kubernetes spawner for JupyterHub
https://jupyterhub-kubespawner.readthedocs.io
BSD 3-Clause "New" or "Revised" License
536 stars 301 forks source link

Lower needed privileges for user namespaces #749

Open xhejtman opened 1 year ago

xhejtman commented 1 year ago

Proposed change

Currently, kubespawner requires rich cluster role permissions to get all pods and other objects when user namespaces are enabled. This makes it problematic to deploy to non-admins.

I believe the code could be changed so that only namespaces created by the hub are scanned, and no additional permissions are required for such namespaces. Would it be possible to make this change?

What do you think?

welcome[bot] commented 1 year 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:

manics commented 1 year ago

I don't quite understand what you mean. If the hub needs permissions to create namespaces for users doesn't that require a ClusterRole? How would it be restricted? Do you have an example of an RBAC role you think is suitable?

xhejtman commented 1 year ago

Basically, user can usually create a new namespace. (at least with default roles we use). Since this new namespace is created by the user, he has control over the namespace (list pods and so on).

However, jupyterhub needs cluster role to list all objects at cluster scope which is not necessarry, it should list only individual namespaces the hub has created.

This situation allows a user deploy only variant without user namespaces, he cannot deploy variant with user namespaces, because he cannot possess clusterrole allowing to list all cluster-scoped objects.

Is it more clear now or should I try to explain better?

xhejtman commented 1 year ago

Note, this request is not about adding/changing RBAC, code update would be needed to not list objects at cluster scope: https://github.com/jupyterhub/kubespawner/blob/dbacf2b8a1f135d810478b5d605e0a8370c0ac90/kubespawner/reflector.py#L270

manics commented 1 year ago

I still don't understand. The Hub runs under a single K8s service account. The default in Z2JH is a Role which only works in a single namespace https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/56c921de05ffeed559fe906972975856e4639cb6/jupyterhub/templates/hub/rbac.yaml#L2-L14 If a user has a namespace that is different from the hub namespace then the hub won't be able to list the user's pods with just a role, since it won't allow cross-namespace access. If you just want users to run JupyterLab themselves there's no need for JupyterHub, they can create a JupyterLab pod directly.

xhejtman commented 1 year ago

OK, so another attempt.

Hub runs, e.g., in the namespace jupyterhub-ns. the service account of the hub has RBAC right to create new namespaces. So it creates jupyterhub-a-ns. Because the new namespace has been created by the service account, it has either implicit rights on this namespace or it can assign the same rights to this namespace as currently possess, and can create, list, delete pods in this new namespace.

However, the service account still cannot list/get/delete pods from any namespace at cluster level and this is not desired.

So, the current implementation of user namespaces requires cluster-role allowing to list pods from all namespaces, which cannot be allowed for ordinary user so he cannot deploy his own instance of jupyterhub with enabled user namespaces.

The use case here is, that a user can run his own instance of jupyterhub with enabled user namespaces, but it does not mean that the hub should utilize user's namespaces. The hub can run in one of the user's namespaces and then the hub creates namespaces via the sevice accounts which allows the service account to access these new namespaces even without special clusterole. Don't you agree?

jpperdon commented 1 year ago

Plus 1 on this since we are looking for a use case where users/team are separated by namespace to isolate all their notebooks specific to them. Other integrations as well are heavily reliant on service account like AWS IRSA or Hashicorp Vault. If there's a make_svc_account, this would improve management and lab experience.