Would like to see if there’s a way to support the following scenario:
A. A dask cluster running on N nodes each running as a non-human user (e.g. dask-svc)
B. Human users running python programs from their desktops as a human user (e.g. myuser), connecting to the cluster described above.
Currently, it seems that work sent from myuser to the cluster executes on the cluster machines as dask-svc. This, in itself, may be fine. However, there may be cases where the code executing on the cluster needs to access a database, where the preference would be to present the myuser identity to the database rather than the dask-svc identity.
Ideally, this would be done through something like Kerberos tickets. This would require the dask-svc identity to have special privileges as far as impersonation goes.
Would like to see if there’s a way to support the following scenario:
A. A dask cluster running on N nodes each running as a non-human user (e.g. dask-svc)
B. Human users running python programs from their desktops as a human user (e.g. myuser), connecting to the cluster described above.
Currently, it seems that work sent from myuser to the cluster executes on the cluster machines as dask-svc. This, in itself, may be fine. However, there may be cases where the code executing on the cluster needs to access a database, where the preference would be to present the myuser identity to the database rather than the dask-svc identity.
Ideally, this would be done through something like Kerberos tickets. This would require the dask-svc identity to have special privileges as far as impersonation goes.