rainwoodman
commented
3 years ago This is probably not going to work. The agent must run as the nodes account of the pool, which probably means all users of the service must be made members of the node account of the pool, and thus we are in a similar situation as using 2 robot accounts.
I am not so familiar with the security model of GCS to be certain about this, and will poke about this a bit more.
We currently use two pools, each with its own robot account:
gke-singleuseris a robot account with no privileges.gke-hubis a bit trickier.Therefore, through gke-hub, all users are granted the privilege to manage the cluster / nodes. This is not only through jupyterhub, but also though regular gcloud commands any member of gke-hub can likely connect to other user's container as root.
I propose we switch to a three pool model:
All users are members of gke-proxy, which has no privileges. gke-hub is granted the privilege to manage the cluster / nodes. gke-singleuser is granted no privilege neither.
This way the user at most acts as gke-proxy, which has no privileges, and no user can access other user's instances via gcloud. If a jupyter-singleuser instances (as gke-singleuser) decides to re-authenticate as a real cloud user, no other users of the service can access the cloud secrets in this instance.
I'd also note that we don't really need WID in either this proposed new 3 account setup or the current 2 account setup. In the future we may be able to find a way to allow jupyter-hub (as gke-hub) to start jupyter-singleuser instances as the real user via the WID mechanism.