Lower needed privileges for user namespaces

[xhejtman]

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]

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.

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

[manics]

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]

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]

Note, this request is not about adding/changing RBAC, code update would be needed to not list objects at cluster scope:

kubespawner/kubespawner/reflector.py

Line 270 in dbacf2b

ns_str = "all namespaces"

[manics]

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]

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]

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.