Skip to content
This repository has been archived by the owner on Mar 2, 2022. It is now read-only.

kubernetes non root #153

Open
dshakey opened this issue Jun 15, 2019 · 11 comments
Open

kubernetes non root #153

dshakey opened this issue Jun 15, 2019 · 11 comments

Comments

@dshakey
Copy link

dshakey commented Jun 15, 2019

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
Copy link
Contributor

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
Copy link
Author

dshakey commented Jul 17, 2019

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

@nathanweeks
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Member

cboettig commented Jan 6, 2020

👍 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
Copy link

yug0slav commented Jul 6, 2020

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
Copy link

stubclan commented Jul 7, 2020

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

@yug0slav
Copy link

yug0slav commented Jul 7, 2020

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

@cboettig
Copy link
Member

cboettig commented Jul 8, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants