- Security of running jobs
When using GitLab Runner you should be aware of potential security implications when running your jobs.
Generally it's unsafe to run tests with
shell executors. The jobs are run
with user's permissions (gitlab-runner's) and can steal code from other
projects that are run on this server. Use only it for running the trusted builds.
Docker can be considered safe when run in non-privileged mode. To make such
setup more secure it's advised to run jobs as user (non-root) in Docker containers
with disabled sudo or dropped
On the other hand there's privileged mode which enables full access to host system, permission to mount and unmount volumes and run nested containers. It's not advised to run containers in privileged mode.
More granular permissions can be configured in non-privileged mode via the
When using the private Docker images support described in
advanced configuration: using a private container registry
you should use
always as the
pull_policy value. Especially you should
always pull policy if you are hosting a public, shared Runner with the
Let's consider such example, when pull policy is set to
- User A has a private image at
- User A starts a build on a shared runner: The build receives registry credentials and pulls the image after authorization in registry.
- Image is stored on shared runner's host.
- User B doesn't have access to the private image at registry.example.com/image/name.
- User B starts a build which is using this image on the same shared runner as User A: Runner find a local version of the image and uses it even if the image could not be pulled because of missing credentials.
Therefore, if you host a Runner that can be used by different users and
different projects (with mixed private, and public access levels) you should
if-not-present as the pull policy value, but use:
never- if you want to limit users to use only image pre-downloaded by you,
always- if you want to give users possibility to download any image from any registry.
if-not-present pull policy should be used only for specific Runners
used by trusted builds and users.
Read the pull policies documentation for more information.
Note: This applies to installations below 0.5.0 or one's that were upgraded to newer version.
When installing package on Linux systems with Docker installed,
will create user that will have permission to access
Docker daemon. This makes
the jobs run with
shell executor able to access
docker with full permissions
and potentially allows root access to the server.
SSH executors are susceptible to MITM attack (man-in-the-middle), because of
StrictHostKeyChecking option. This will be fixed in one of the future
Parallels executor is the safest possible option, because it uses full system virtualization and with VM machines that are configured to run in isolated mode it blocks access to all peripherals and shared folders.
Runners use a token to identify to the GitLab Server. If you clone a runner then the cloned runner could be picking up the same jobs for that token. This is a possible attack vector to "steal" runner jobs.