### Problem to solve Right now when Gitlab starts up a container to be used in the CI/CD pipeline, it is always started as the default user in the image which is usually the root user. While technically this is fine, it is **not** a good security practice and it actually makes doing some things harder. Gitlab's Docker runner should be able to start a container with a specific user and group. ### Further details In terms of security, you shouldn't be running as a root user because if the Docker runner is setup incorrectly, if a malicious user has a container escape exploit, they now have root on the system. It also means that if someone irresponsibly mounts something from the host into the container, the root user in the container can do whatever they want with that mount. Now you can get around this to some extent by using user namespaces and strict mount control, but also requiring that the attacker also needs another privilege escalation exploit before getting root would be a very good thing. As for some tasks being harder, its becoming more common now for tools to check if they're running as root and if so, not run properly without an explicit flag. An example I ran into recently with this is the `pnpm` command. It uses a lifecycle library for NPM that does nothing if run as root. You can get around this by setting the `unsafePerm` option but the preferred solution from NPM is to just not run as root. From a purely Docker perspective, this is easy to do since the official Node images come with a node user and Docker supports switching users when running a container. ### Proposal Adding an additional option to the `.gitlabci.yml` spec to support a specific Docker user and group would alleviate these problems. This could look something like this: ```yaml image: node:10.5.0-alpine docker_user: node docker_group: node ``` Alternatively, instead of `docker_user` and `docker_group` you could make it simply `user` and `group`. The benefit of the former approach is that it's more explicitly about Docker. The latter approach is more general and might be applied to some other runner type if applicable. I have no real preference and would leave that up to people who know the other runner's to make the call. ### What does success look like, and how can we measure that? Can a Docker container for a specific job be started as a specified user/group. ### Links / references * [Docker Run](https://docs.docker.com/engine/reference/commandline/container_run/) (See the options section). * [Docker Security](https://docs.docker.com/engine/security/security/#linux-kernel-capabilities) <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->