<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=537603) </details> <!--IssueSummary end--> MR: Pending <!-- NOTE: For context on MR heading, see: https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/index.html#relationship-of-issues-to-mrs --> ## Description Context - https://gitlab.com/groups/gitlab-org/-/epics/15648#note_2449891058 As part of [Workspaces ADR 005: Explicitly define the user/group ID of the containers at runtime](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/workspaces/decisions/005_explicitly_set_user_group_id_of_containers/), 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](https://docs.gitlab.com/user/workspace/create_image/) 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 https://gitlab.com/gitlab-org/gitlab/-/issues/545310+ , 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)](https://kubernetes.io/blog/2024/04/22/userns-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 https://gitlab.com/gitlab-org/gitlab/-/issues/545310+ 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 - https://gitlab.com/groups/gitlab-org/-/epics/17851+ ) <!-- TODO: What kind of issue is this? Please uncomment and include one of the following: /label ~"type::feature" /label ~"type::bug" /label ~"type::maintenance" --> <!-- OPTIONAL: Is this a feature/enhancement? - Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole. - Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality. --> <!-- OPTIONAL: Is this a bug? Please uncomment and include the following: - **Current behavior:** - **Expected behavior:** - **Steps to reproduce:** - **Additional information:** please include VSCode version, browser dev tool logs, etc that might be helpful to debug the issue! --> ## 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. <!-- NOTE: Feel free to expand with more sections and headers as needed --> <!-- DO NOT TOUCH BELOW -->