Skip to content

Allow running of non-root user in Docker Container during CI/CD pipeline

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:

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

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.

Edited by 🤖 GitLab Bot 🤖