[go: up one dir, main page]
Skip to content

Investigation: Remove runAsUser to allow users to bring off-the-shelves container images

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

MR: Pending

Description

Context - &15648 (comment 2449891058)

As part of Workspaces ADR 005: Explicitly define the user/group ID of the containers at runtime, we decided to explicitly set the security context with which a Workspace(Kubernetes Pod) will run. This was to primarily prevent privilege escalation for security reasons.

Since we used to clone the project as an init container, the files cloned have a specific user/group ID as the owner. To allow users to be able to access the files in their workspace with the appropriate file permissions, we need all the containers to be run as the same user/group ID as the init container cloning the project.

Since we will explicitly set the linux user/group ID of the user which will run the workspace, the container images used to create the workspace should follow the practices around running a container image with arbitrary user ID i.e. at the container build time, the user should not make any assumptions about which user/group ID the container will run as and give file permissions accordingly at build time.

This issue is about how we can allow users to being off the shelf container images to make it easy for them to use Workspaces. Additionally, there are legitimate use-cases where the user to run the container needs to be controlled by the end user.

As part of Move project cloning to post start event (#545310 - closed) , we have changed this behaviour to move the project cloning from the init container to a post start event in the workspace. This open up some opportunity for us to simplify things further.

Let's say we have a devfile with 2 container images - image1 and image2. Let's say image1 is the main container image where we will be injecting the IDE. My proposal is to let all container images run as whatever user it is configured as. This way, we don't need to impose any restrictions on what image1 is or how it is built because we will not run into file permissions issue.

Container Image Dockerfile User Run as user(existing) Run as user(proposed)
image1 1234 5001 1234
image2 4321 5001 4321

We can achieve this by not explicitly setting runAsUser which we do now. There are some other technical questions we need to answer regarding other fields like runAsNonRoot and fsGroup/fsGroupChangePolicy options we set on the workspace pod which might impact the behaviour. We'll have to think them through.

Please note, for security reason, we will still not allow to run any off-the-shelf container image whose dockerfile user is 0 (root), at least not until Kubernetes User Namespaces become GA(right now it is Beta). Furthermore, once this feature becomes GA, we aim to utilize it to make our workloads more secure. As per https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/#integration-with-pod-security-admission-checks , the fields that we are proposing to remove as part of this issue e.g. runAsUser/runAsNonRoot are not supported in that mode. So this is a step in the right direction.

Since Move project cloning to post start event (#545310 - closed) is now merged , we need not set runAsUser security context setting. However, not setting runAsUser while setting runAsNonRoot is not ideal because Kubernetes cannot reliably enforce runAsNonRoot and it won't run any container images which do not have userid(not user) set during build time. When someone specifies USER test in their dockerfile, it does not assign an userid necessarily to it.

So if we want to remove runAsUser, we now need to think how we can remove runAsNonRoot as well but still maintain the same security posture where we do not allow a user to run as root(0); at least not until Kubernetes User Namespaces becomes GA (Related issue - Enable Kubernetes User Namespaces by default fo... (&17851) )

Acceptance criteria

  • Feasibility of moving project cloning outside of init container to the main container of the workspace.
  • Feasibility of not setting runAsUser and its impact.
  • Feasibility of not setting runAsNonRoot and its impact.

Implementation plan

N.A.

Edited by Vishal Tak