kubernetes non root

[dshakey]

is it possible to make the docker image not to run as root. kubernetes pod security policy does not allow pods to run as root.

[nathanweeks]

I've deployed Rocker containers on Kubernetes as non-root; the protocol is similar to that for running Rocker using Singularity on a (multi-user) HPC cluster: set the PASSWORD environment variable to a suitable password, and launch rserver --auth-none=0 --auth-pam-helper-path=pam-helper. I don't have access to an example Kubernetes manifest at the moment, but hopefully that's enough info to get you started.

[dshakey]

ill give this a try, can I use the normal rocker image?

[nathanweeks]

Yes. A couple caveats I forgot to mention:

1. ADD=shiny won't work (can't install Debian packages as an unprivileged user)
2. R_LIBS_USER is hard-coded in /usr/local/lib/R/etc/Renviron :

   R_LIBS_USER='/usr/local/lib/R/site-library'

   This will cause any package installation by the user to fail unless they override it somehow. One possible fix might be to "overwrite" it at container launch time by bind-mounting a modified version of Renviron that excludes that line (in Kubernetes, this might be done via ConfigMap); another option (as illustrated in the Singularity example) is to create $HOME/.Renviron with R_LIBS_USER set to a path in the user's home directory (a user's .Renviron overrides the side Renviron).

Thinking aloud, it seems Rocker could more conveniently facilitate R package installation in such environments where users cannot run it as root if it tweaked the site Renviron to at least allow R_LIBS_USER to be overridden via environment variable; e.g.:

R_LIBS_USER=${R_LIBS_USER-'/usr/local/lib/R/site-library'}

[eddelbuettel]

Sure. Note that that is /usr/local/ and hence "us", i.e. @cboettig's Dockerfile.

The Debian packages generally do this:

edd@rob:~$ grep R_LIBS_USER /etc/R/Renviron
R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.6'}
#R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.6/library'}
edd@rob:~$

[cboettig]

@nathanweeks good suggestion, that does make sense and happy to take a PR for that!

Though as you point out, we generally expect a user to override that with a $HOME/.Renviron or a project .Renviron, e.g. with a bind mount. (e.g. particularly if you're pointing to a user-level library like /home/rstudio/R, it makes more sense to me that you would set that in at the user level .Renviron rather than the system level /usr/local). Anyway, either is good.

@dshakey thanks for the issue and feel free to close this if it resolves the problem!

[nathanweeks]

It looks like the hardcoded-R_LIBS_USER issue was resolved in r-ver:3.6.1: https://github.com/rocker-org/rocker-versioned/blob/master/r-ver/3.6.1.Dockerfile#L112

[cboettig]

:+1: yup, thanks @nathanweeks for mentioning. (should also be propagated forward now)

I haven't explored kubernetes use all that much, but it's something I'd like to include in our planned update to create more extensive community documentation. My current approach to deploy on kubernetes is just something like:

 kubectl run --image=rocker/rstudio rstudio-app --port=8787 --env="PASSWORD=cluster"
 kubectl port-forward --address 0.0.0.0 deploy/rstudio-app 8777:8787  &

which seems to be roughly the equivalent of our standard docker deploy for the image,

docker run --name rstudio-app -p 8777:8787 -e "PASSWORD=cluster" rocker/rstudio

but I'm still a k8s newbie, there's probably much more elegant approaches. (I actually failed to figure out how to correctly expose the port to a public ip when using the perhaps more typical approach of writing an deployment.yml configuration and using expose deployment...)

[yug0slav]

s6-mkdir: warning: unable to mkdir /var/run/s6: Permission denied

if you try to add spec: securityContext: runAsUser: 1234

and UID: 1234 to image env

Is anybody able to run rocker images on k8s with noroot/noprivilaged psp?

[stubclan]

@yug0slav Have you tried changing SecurityContext as root? runAsUser : 0 ?

[yug0slav]

Running with root UID is not allowed in our clusters, it fails to validate against podsecuritypolicy.

[cboettig]

RStudio server expects to run as root. The server supports multi-user logins where user accounts are tied to the underlying host (container) users. Likewise, s6 init system, like most init systems, expects to run as root.

In principle it should be possible to get an rsession to run without the rserver. (Typically the rserver launches the rsession automatically as the user that logged in).

Unfortunately I haven't quite figured out how to set the environment appropriately so that rsession correctly finds the R libraries and files. See https://github.com/rocker-org/rocker-versioned2/blob/master/scripts/rsession.sh