MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description When we generate the Kubernetes resources(e.g. Deployment) from the devfile, we [explicitly set the user id that it should run as](https://gitlab.com/gitlab-org/gitlab/blob/7ce536de6bbb3f9469b9574b44e5c80b0c61bc5e/ee/lib/remote_development/workspaces/reconcile/output/devfile_parser.rb#L85). If memory serves me right, setting the `securityContext` in the pod configuration was a recommended security practice. However, what point does setting the `runAsUser` serve? Can we remove it? Removing it would significantly simplify our documentation which is a mess right now. ## Acceptance Criteria - [ ] A decision if we can remove `runAsUser` attribute of the security context. If the answer is no, the reason for it. - [ ] Can we remove some other attributes as well? ## Technical Requirements TODO: Fill out or delete (optional) [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete (optional) [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete (optional) [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete (optional) [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->