Skip to content
Snippets Groups Projects
Unverified Commit ac965e54 authored by HonkingGoose's avatar HonkingGoose Committed by GitHub
Browse files

docs(gitlab bot security): update links (#18407)

parent d4687b32
No related branches found
No related tags found
No related merge requests found
...@@ -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.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment