Skip to content
Snippets Groups Projects
Select Git revision
20 results
Blame Permalink
gitlab-bot-security.md 6.44 KiB 
title: GitLab bot security

GitLab bot security

Make sure you understand GitLab's security model, before you run a "bot" service like Renovate on GitLab, particularly the pipeline credentials.

!!! warning If you have any doubts or concerns about this content that could affect other users, please follow our Security Policy and report them confidentially.

CI_JOB_TOKEN permissions

The concept of CI_JOB_TOKEN permissions was overhauled in GitLab release 8.12, jobs now run with the permissions of the user account which triggered the pipeline. For security reasons the token was limited to read-only permissions and a limited set of API endpoints, but it’s been extended to allow write access to the GitLab Package Registry. Any pipeline triggered by a user account thus has permissions to:

  • read any repository which that account has access to
  • publish packages to them

With the current GitLab CI permissions model, you should only commit to a project which you trust completely. Because that project could maliciously steal repository data, publish fake releases, or spam releases.

Risks of hosting a Renovate GitLab app/bot/service

With GitLab's current security model, we find the risks of running a public bot service like Renovate are too high. Therefore we stopped hosting Renovate on GitLab, and are waiting for a better security model.

You should remember that when accounts are invited into projects or groups on GitLab, acceptance happens automatically. This was a useful feature to leverage for a shared service.

If you are running a self-hosted Renovate service, we recommend you:

  • Run a shared service only within projects which have shared visibility/security within the users, or which have a low risk that a user would try to gain access to a private project they don't otherwise have access to
  • If running with autodiscover, also configure a value for autodiscoverFilter so that the bot can't be invited to projects or groups you don't intend

Security solutions and workarounds

The following research notes may help you to assess the GitLab bot security risk.

Public projects only

If you only run a bot service on public projects, the risk of unauthorized users accessing private project data is zero. But malicious users can still spoof or spam packages to any other public project they are not a member of, this rules out this approach for a public hosted service.

A public-visibility-only bot service should be low risk for most self-hosted GitLab instances. But you can't stop users from inviting the bot into private projects by accident, which is risky.

Project Access Tokens

Project Access Tokens (PATs) are a recently added feature for GitLab. The main downsides to using PATs for a shared bot service are: