Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Ruunig Che and Che worksapce as non root user.

Hi Serhii,

 

I will try your suggestion to get Che workspaces to run using another user id by changing configmap.yaml instead of modifying a specific stack to include runAsUser and fsGroup.

I got Che to start under an unprivileged user by changing the che/template/deployment.yaml file to include securityContext.runAsUser and securityContext.fsGroup

 

I am also interested in getting the initial content of a workspace’s /projects directory cloned to a newly created volume that would be mounted onto /projects.

The goal is to have the content of the main container’s /projects shared between the main container and its sidecars.

https://docs.docker.com/storage/volumes/ indicates that it is possible to do so but it did not work for me.

I created an image, added /projects and some contents under the directory. But once the workspace is up and running the contents do not appear in /projects.

 

Thank you for your feedback.

 

Son

 

 

From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx] On Behalf Of Serhii Leshchenko
Sent: Friday, March 15, 2019 3:42 AM
To: che developer discussions
Subject: Re: [che-dev] Ruunig Che and Che worksapce as non root user.

 

Hi, 

 

Helm chart has hardcoded values for runAsUser and fsGroup[1] that will be used for workspaces related pods.

 

So,

> Can this be resolved?

> Is there a way to change user/group ids of /projects? If so, how?

 

You can change values there to any you want. "NULL" if you do not want to set any value.

You're welcome to contribute and make these properties configurable with helm chart values.

 

> Are there reasons why /projects does not belong to the user/group as specified by the securityContext settings?

 

Root as default was set some time ago, because otherwise there were issues with PVC subpathes which are used by 

common PVC strategy configured by default in helm chart[2]. But I can be wrong here.

 

Sorry if my answer is not detailed enough but I hope it will help.

Feel free to ask more if needed.

 

Regards,

Serhii.

 

 

 

On Thu, Mar 14, 2019 at 5:12 PM Nguyen, Son <Son.Nguyen@xxxxxxxxxxxxxx> wrote:

Hi,

 

I posted this question here https://mattermost.eclipse.org/eclipse/channels/eclipse-che but had no feedback. So, I hope I can get information from the Che Dev community.

 

For security reasons, I would like to start Che and workspaces using a custom stack as a non-root user.

 

Using the latest Che helm chart to deploy it in a Kubernetes cluster, Che and Che.workspaces are run as root. At least that's what I see when shelling into the container and using the id command.

I modified a custom stack and used securityContext.runAsUser and securityContext.fsGroup at the container level to run as an existing user. It seems to come up with that user id.

However, the problem seems to come from the fact that /projects is owned by root:

drwxr-xr-x. 3 root root 4096 Mar 12 19:45 /projects/

 

Clearly, this does not bode too well with that user id when s/he tries to write to /projects.

 

Can this be resolved?
Are there reasons why /projects does not belong to the user/group as specified by the securityContext settings?

Is there a way to change user/group ids of /projects? If so, how?

Are there any other options?

 

Is this a configuration matter or is Che only working with root privileges?

 

Any feedback is greatly appreciated.

 

Son Nguyen

 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


 

--

Serhii Leshchenko

SENIOR SOFTWARE ENGINEER

Red Hat 

 

Back to the top