I am in the process of installing and running Rstudio workbench in AKS cluster, I am using the latest version of the docker image to do so and also using the helm charts which is available in the git repo with some customization.
I am also integration Okta for user authorization using SAML assertion.
I want to understand how will be user provisioning is done for rstudio workbench when we run the image as docker container, all the documentation of user provisioning in rstudio documentation is based on the VM configuration. I am looking for an automated way for user provisioning in rstudio.
Is there any documentation on how we do it using helm charts.
Thanks for reaching out here! What modifications did you need to make to the helm chart, if you don't mind me asking? Anything features we are missing that could be helpful? Please feel free to submit issues / PRs!
Unfortunately user provisioning for Workbench is still in a very VM-like world today. The way we generally see administrators do this is via an AD or LDAP server and sssd used to sync users to the linux OS. I realize this is not a great fit for Kubernetes, the Cloud, or Okta, because such a server may not be available.
In the meantime, another workaround might be writing a little sidecar service that creates users based on requests to the Okta API, a list in a configmap, etc. The Workbench container has supervisord as its init mechanism, so it should be fairly straightforward (though far less than ideal) to inject such a service. One very important element to keep in mind is that users' UIDs should always remain consistent across the cluster, and their linux username should match an assertion attribute coming from Okta (which attribute can be configured).
We are aiming for a better long-term solution to this problem using SCIM, but unfortunately do not yet have any expected ETA on when such a feature might be available for release.
I realize this is not much good news Please feel free to reach out to your account representative if you would like to set up a call to discuss these sorts of items directly!
One important feature which was missing is have mechanism for synching the secrets and certificates from the Vault, since are hosting in Azure I have modified the charts to add a SecretProviderClass and sync the secrets and certificates which are required using AKS inbuilt CSI driver. This will be a very good feature to have which will utilize the any CSI driver provider for synching the required secrets and mount the volume within the container which can be utilised by the data engineers instead of sharing the keys or manually creating the secrets within the secret store. I thought I will submit a PR, but the helm chart is not written with the way other chart templates are created, may be I will submit a PR after doing some cleanup.
Thats a bummer to hear, I wanted to avoid the side car since I want to limit the number of containers which runs within the workbench pod. Well I have found another way like an hack to provision the user, i am using that mechanism it works for now still encounter permission issues time to time with the folder creations with this mechanism, fine tuning it.
Now that I got the workbench and sessions are running, I will reach out to our account representative since I am having an issue with jupyter notebook kernal startup, its taking too much time and crashes frequently.
I am definitely interested in adding a SecretProviderClass output to the chart. The other option would be using extraObjects, which is designed to be a placeholder for other CRDs necessary.
Would definitely love to hear more about the solutions you came up with for user provisioning. Hopefully things are in a better / more consistent state by now!
Please feel free to submit issues / PRs!
Please feel free to reach out to your account representative if you would like to set up a call to discuss these sorts of items directly!