@@ -10,8 +10,8 @@ You should understand GitLab's security model, before deciding to run a "bot" se
...
@@ -10,8 +10,8 @@ You should understand GitLab's security model, before deciding to run a "bot" se
## `CI_JOB_TOKEN` permissions
## `CI_JOB_TOKEN` permissions
The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html), jobs are now run with the permissions of the user account which _triggered_ the pipeline.
The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/), jobs are 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](https://docs.gitlab.com/ee/api/README.html#gitlab-ci-job-token).
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](https://docs.gitlab.com/ee/api/index.html#gitlab-ci-job-token).
Any pipeline triggered by a user account thus has permissions to read any repository which that account has access to as well as publish packages to them.
Any pipeline triggered by a user account thus has permissions to read any repository which that account has access to as well as publish packages to them.
With the current GitLab CI permissions model, you should avoid committing to any project which you don’t trust completely, because that project could maliciously steal repository data, publish fake releases, or spam releases.
With the current GitLab CI permissions model, you should avoid committing to any project which you don’t trust completely, because that project could maliciously steal repository data, publish fake releases, or spam releases.